Father of Unix Ken Thompson checkmated: Old eight-char password is finally cracked Back in 2014, developer Leah Neukirchen found an /etc/passwd file among a file dump from the BSD 3 source tree that included the passwords used by various computer science pioneers, including Dennis Ritchie, Ken Thompson, Brian Kernighan, Steve Bourne, and Bill Joy. As she explained in a blog post on Wednesday, she decided at …
This post has been deleted by its author
until about 6 years ago (or more, i don't remember), hotmail.com passwords were truncated at 15 characters before being passed to the back end, and 6 years ago (or whenever it was) they changed their login page to stop truncating the password before submitting it. this meant that my 16 character password that I had been using suddenly stopped working. I was able to log in by simply pasting my password and hitting backspace.
Really? I'd have told you to do my password then gone over your head to find out why you were fuckarsing around cracking passwords instead of doing some work....
Really? I always thought a good sysadmin should do exactly that?
Get rid of all the silly requirements that don't actually make passwords harder to guess, and just run a constant crack against everyones password. When found, force a password change on the account, send the user an email explaining why.
The people with good passwords don't get bothered, the people with poor ones will hopefully soon learn.
Much better than 'change your password every 3 seconds' that seems so popular.
Sweary passwords are ok until you're logging in to a machine with a big screen monitor in front of an audience, and you type your password into the username field.... fortunately I realised at 4 innocuous enough characters in... but I've been a bit more careful since. I don't know why there isn't an option to blob out usernames.
"Several of my passwords over the years have contained swearing"
ALL of mine do. However, they're foreign cuss words (and nothing easy like scheisse) from several languages. I also include idiosyncratic spelling for certain words. So much for dictionary attacks, it'll have to be random-character and grind grind grind.
The Reg statement is correct...
Modern, salted passwords prevent the use of rainbow tables, but those weren't used here. It was brute-forced.
Modern hash algs use more CPU time, but only by a factor of 3X or so.
Meanwhile, each character added to lengthen your password *exponentially* increases the time needed to brute-force it, as long as it is actually a random selection and not a predictable variant.
Sorry, if it doesn't have an adjustable iteration count, it's not a modern password hash algorithm.
(And no, I don't make the individual UX/load/security tradeoff for every individual machine either, even though for local auth on a desktop, where the password is checked only on login/unsuspend/screenunlock, I could easily set the iteration count to the equivalent of half a second without any serious effect.)
Sorry, if it doesn't have an adjustable iteration count, it's not a modern password hash algorithm.
Even that isn't enough. If it's not memory-intensive (and not just compute-intensive), it's not a modern password hash algorithm. The state of the art has moved on from simply using large-range cryptographic digests with salts, like SSHA512. Simple adjustable-compute-cost algorithms like PBKDF2 (with common PRFs such as HMAC-SHA2) and bcrypt are starting to get long in the tooth.
Argon2 and scrypt qualify as a modern password hash algorithms.
This post has been deleted by its author
This post has been deleted by its author
>You run the password safe on your own machine. It's not in the cloud.
Okay if you only run one device etc. etc.
Once you start using multiple (real/virtual) devices (ie. ubiquitous computing) you need that safe to be in the cloud and sync'd.
We, in IT, need to simply accept that Joe Public will want to write credentials down and will want to use simpler passwords. Yes, there are security risks however, we can mitigate some by good design of the login process (specifically the handling of failed attempts, but also use additional information to increase effective password length) and others by appropriate security of the at rest credentials on the server.
"you need that safe to be in the cloud and sync'd."
What if that option were not available to you? How would you handle it?
Well, to me 'cloud' is both public and private, what is key is simplicity of access and sync. which implies some form of networked solution.
You'd just sync one device to another directly.
Interesting, distributed/mesh credential management. definitely possibly via bluetooth. Support for personal area networking is probably a must have feature for credential managers going forward.
Or do you genuinely have a situation where you never have two devices in the same place at the same time?
Well, I genuinely have times when devices are in the same place but on different networks, but both with internet access. Yet both could be associated via the same bluetooth/personal area network.
This post has been deleted by its author
You pick the 'phone up, access your private database on it with your master password, and read her the supermarket password.
How it works in the real world:
My partner and children know my phone's unlock code - it helps them answer the phone, send messages on my behave whilst I'm driving.
Because it is inconvenient to always have to enter the master password (typically 12+ characters), the "keep me logged in" is ticked. But as this is the Sainsbury's account, my partner already has the password on their devices...
An increasing pain (when running joint accounts etc.) is the upgrade of security on online bank card transactions, where as part of the transaction the bank sends a code to a (and it is only one) mobile phone - which naturally isn't the one to hand...
you can run the password safe on your cellphone. It's that portable device you have
Right up until you don't have it, because you forgot it, or the battery ran down, or you lost it, or it was stolen, or it broke.
Yes, let's use a physical key that's difficult to copy, valuable, and fragile. That's a terrific idea. Nothing could possibly go wrong there.
Staple Horse Battery is incorrect. Here's why:-
https://diogomonica.com/2014/10/11/password-security-why-the-horse-battery-staple-is-not-correct/
(Sigh. You could at least try to get the phrase correct.)
Monica makes some decent points, but he's arguing a different question. His complaint about Munroe's comic is ill-founded. He also relies on incorrect assumptions.
First, he claims "As a community we did a great job incentivizing the use of bcrypt and scrypt, and humiliating those who use bad password hashing mechanisms". That is utter rubbish. In breach after breach we see disclosures of password-verifier databases that do not use strong hashing mechanisms. It will be years before there's a decent probability that exposed verifiers won't use weak hashes. And unless a user knows that the entity computing the verifier is using a strong hash, long passphrases beat short passwords with a complex alphabet. Munroe is completely correct about that.
Second, even against resource-intensive hash algorithms like scrypt and Argon2 (bcrypt is not in the same class, since it's only CPU-intensive), dictionary attacks with reasonable-size dictionaries still work well. And users often still choose weak passwords that appear in such dictionaries.
Third, Monica fails to consider attackers who steal resources (e.g. using leaked AWS keys), and attacks which iterate over IDs using the same password, avoiding lockout and common throttling mechanisms. Assuming that brute-force is only feasible for nation-state attackers is flat-out wrong.
Finally and most importantly, Monica's basic argument is that human-memorized passwords are the wrong protection model, and we should encourage something else. Well, essentially everyone in IT security has been saying that for decades. It's not a controversial or underexposed position. And it's irrelevant to questions about how to structure strong human-memorable passwords, which is still a requirement unless you want users to rely exclusively on other classes of verifiers (the "what you have" and "what you are" classes). And there are significant issues with the latter position, which introduces a significant attack surface with some very bad failure modes.
In any case, arguing against human-memorized passwords does not respond to Munroe's comic. It's a different threat model. You can't claim to make motorcycles safer by telling everyone to ride the bus instead.
"attacks which iterate over IDs using the same password"
There's another place where chances are being lost - using the same ID on multiple sites. It doesn't help that so many sites insist on using the customer's email address as an ID and most people only have one. Dishonourable exceptions in my case are bank and GP both of whom allocate reasonably predictable IDs.
I’m nit sure if anyone looks at the those passwords, they just script something to push all the hacked accounts at different sites to see what sticks.
As a side note, an 8 char password of lowercase letters and numbers of mine was lost as part of the Adobe hack. According to Have I Been Pwnd, it’s never been cracked.
"Just give me the bloody rules UP FRONT!!!"
And please make the rules reflect the importance of the site, too.
One of the most complicated passwords I have is for ARM just to download a frigging datasheet.
Upper case, lower case, numerical, a symbol, eight hundred characters minimum, three runes, a curse in Arameic, and letters in at least six different colours. WTF? To download a datasheet?
Not that long ago I had to create a password for some site that simply told me a password was "unacceptable", with no further details. Now I've forgotten what site it was. I think I simply gave up and didn't create an account.
And I remember some time back using one which silently removed "special characters" from the password entry fields - and used different filters for password creation and user authentication. Took a while to figure out what was going on there.
(Of course, any application which has to filter out special characters from user input is broken and the developers should be sent for remedial training. Injection attacks are a real problem, but you fix them by not passing tainted data into evaluation mechanisms, not by blocking user input. Just the other day I was asked to write a comment on a site which - again silently - stripped out most punctuation characters, including semicolons, parentheses, and hyphens(!). As if those aren't fairly important in English prose.)
>It was good enough at the time, and easily swapped out with a stronger algorithm.
Well given what was involved:
"The cracking effort took more than four days on an AMD Radeon RX Vega 64 running hashcat at a rate of about 930MH/s."
I suggest it is still good enough for many purposes today.
Obviously once someone creates the relevant rainbow table things are a little different.
I recalled that was the case too. Anything you typed after the first 8 characters was truncated and did not affect the hash.
All of which is a bit odd as the password guessed by the computation is 13 characters. This suggests it is not Ken's password but something else that when not truncated hashes to the same value.
This post has been deleted by its author
and easily swapped out with a stronger algorithm.
Pardon? Easily? I remember it as a major headache back when I was doing it in the early 90s.
But maybe you're thinking of when people started trusting this modern shared library malarkey and blithely accepting the risk of taking out every method of logging into the machine just because of a transient data error on your SCSI bus, rather than doing it the traditional way of using static linking for anything that was recovery-critical.
On a unix system yes, the algorithm would have been DEScrypt.. Many years ago someone built an FPGA setup which could brute force any DES password in a few hours.
DES passwords also had a maximum length of 8 characters, so it simply wasnt possible to have a longer password.
Modern unix systems would use crypt-md5, crypt-sha512 or bcrypt which are much stronger than DES and support much longer passwords.
On the other hand, even the latest versions of windows still use NTLM which is based on MD4. They also use an AES based algorithm as well, but it's not possible to migrate entirely to a new algorithm like unix can because the hashing algorithms are an inherent part of network authentication protocols among other things - so the newer algorithm can largely just be ignored.
NTLM is not salted, although it does support longer passwords than DES, generally NTLM is even faster to crack than DES - especially if you're going after multiple hashes in parallel.
You can also in many cases pass the hash, which renders the encryption algorithm totally irrelevant anyway as the hash becomes an equivalent of plaintext.
> On the other hand, even the latest versions of windows still use NTLM which is based on MD4. They also use an AES based algorithm as well, but it's not possible to migrate entirely to a new algorithm like unix can because the hashing algorithms are an inherent part of network authentication protocols among other things - so the newer algorithm can largely just be ignored.
This hasn't been entirely true for some time now. Plain old Windows, configured for basic local auth, will still use NTLM/MD4, but that's one of many auth options, even for home users.
Network authentication has been standardised on Kerberos/AES for years, though unfortunately MD5-based Kerberos is still a necessary evil for places that still insist on running 15 year old domain controllers.
Look, how many more times?! We only want Windows information from Linux users so we can carry as we always have. Much easier to have massive knowledge of Linux and a fleeting aquatintance with Windows than actually be competent on both.
So post things like "ha ha, Windows is so old fashioned and badly designed that you can't do real work on it!" and you'll fit right in.
> necessary evil for places that still insist on running 15 year old domain controllers
Or for places that have old line-of-business stuff running on old Solaris boxes that are still on an old version of Solaris.
Like wot we used to.
(The version of smbd supplied couldn't accept anything other than NTLM and newer builds of smbd wouldn't build..)
It's worth pointing out that NTLM (and NTLMv2 which uses HMAC-MD5) have been depreciated since 2009, and if you're administering a Windows network these days you should totally disable NTLM and just use Kerberos with AES instead.
This post has been deleted by its author
I had occasion to crack the root password on an ancient SGI Indigo Irix system several years back.
Logged in on a demo account, grabbed the /etc/passwd file, moved the appropriate line to my PC, and
John the Ripper produced the correct root password in less than the amount of time it took me to get a cup of coffee.
"As I understand it an eight character password would have been hashed in a much less secure method back then than now. Modern passwords are hashed in such a way as to take a long time to compute in order to resist brute-force attacks."
While the less secure hash method (likely 25 rounds of DES salted with MD5) is an issue, the length offers little protection against a determined attacker. This took 4 days on hardware worth around £1000 (£770 for a PC, £300 for a RX Vega 64 GPU).
Using a faster setup as detailed here (a mid-range Brutalis at $25k - https://terahash.com/#appliances) you get the performance documented here:https://gist.github.com/epixoip/a83d38f412b4737e99bbef804a270c40
This raises the hash rate from ~1GH/s to 200GH/s for MD5/24GH/s for SHA256/8GH/s for SHA512 so an 8 character password will be found in under a day regardless of hash used assuming it is a crypt password.
Realistically, you want double that password length or longer for anything important. Which then leads to the "use a password manager" advice.
>Using a faster setup ....
This raises the hash rate ... so an 8 character password will be found in under a day regardless of hash used assuming it is a crypt password.
Very useful information, however, given the typical password breech of recent times- a million or so sets credentials, what does this mean?
I suggest that most purposes eg. El Reg login, an 8 character password is sufficient, provided it is based on an uncommon pattern involving mixed alphanumeric and symbol characters. Naturally, as the password breeches have also shown, much depends on how the passwords have been hashed, salted (or not) and stored.
I suggest that most purposes eg. El Reg login, an 8 character password is sufficient, provided it is based on an uncommon pattern involving mixed alphanumeric and symbol characters
So... P@55w0rd!
You're just so much better off with a nice long passphrase. Four random words, slightly randomized variations of their spelling, capitalization, spacing, etc., and you're extremely secure, with no more effort than memorizing a super complex string of random characters. The only valid excuse I've seen for short passwords is cumbersome input devices on phones and the like.
It means that for a typical password breach consisting of e-mail addresses and passwords consisting of salted (so we can't use a precomputed table) SHA256 hashes, we can manage 24 billion hashes (gigahashes or GH) a second on a dedicated hacking rig.
Number of hashes required for a typical password is ((# of possibilities)^(characters in password))/(hash rate/s * time)) to get days required:
Characters
Password set 8 10 12 14
Alpha (lower): <1hr 2hr 46d 85yr
Alpha(upper/lower): 1hr 70d 516yr 1.3Myr
Alpha+Numbers: 3hr 1yr 4.3Kyr 16.3Myr
Alpha+numbers+symbols: 3d 88yr 808Kyr 7.5Byr
This assumes worst case where the entire password space must be exhausted. With dictionary attacks, passwords from previous password dumps and common password patterns (i.e. word##/word19##/wordword##/wordword19## using dictionaries and then same again with symbols as first or last character, common letter/number/symbol substitutions and foreign language dictionaries based on e-mail domain - there are more common patterns as well) you may only need to 1% of the total time to get >90% of the passwords based on typical dumps (https://wpengine.com/unmasked/).
My opinion?
- 8 characters or less is a day or twos effort on a standard gaming PC with a GPU that works with hashcat.
- a 10 character "complex" password is likely to be cracked in under a year if you exist in a previous hack or a common pattern.
- 12 characters means you are probably safe with a complex password against a single determined attacker
- 14 characters should be safe with crypt, even against multiple attackers or attackers with significant resources
- 16 characters will likely still be secure in 5 years. If you are concerned about quantum computing delivering significant increases in performance, move to 20 characters.
There has been a variety of good theoretical feedback.
It would be interesting, given the password lists now in the public domain that form the basis of HaveIBeenPwned for example. To run one of these lists through a cracker to see how many passwords get cracked in say 6, 12, 24, 48 hours, to put some real world handle on these theoretical calculations...
Perhaps some security researcher has already done this?
There are 555,278,657 unique passwords in https://haveibeenpwned.com/Passwords
It would take a matter of seconds to create the hashes for a single, known salt on most modern PC's will likely generate the list at >100M passwords a second. If you have openssl installed, "openssl speed sha512" will give you a good idea of the CPU's hash speed - if you wish to use hashcat, you will also need OpenCL support installed.
If you don't know the salt, then you need to do this for every possible salt to build a rainbow table - assuming Linux with a SHA512 password, the salt is either 2^48 (i.e. 8 characters of base64) or 2^96 (upto 16 characters are specified in the spec but I'm not aware of any mainstream OS's using this) so you still require a lot of time and storage to produce this.
Which leads onto "how do we easily find the salt value?"
If the passwords have been stored securely with SHA512 (i.e. modern Linux), the answer is likely luck in brute forcing the salt, but at 2^48 you have reduced the strength of the password dump to that as finding one salt allows you to quickly find a large percentage of the others and the remaining brute force is significantly easier. But even with a large resource dedicated to this and continuing technology advances, you are looking at more than 2^20 years (i.e. 3x10^10 seconds in a year, 2x10^10 hashes a second, 1x10^7 hosts for a distributed effort).
However... in many of the dumps in the wild, the salt is either not used (i.e. LinkedIn's password dump - ref:https://queue.acm.org/detail.cfm?id=2254400) or there are other weaknesses (i.e. NTLM stored as two 7-character hashes or some IDAM applications require reversible encryption to be enabled on AD for full AD integration) that may make this much easier and once you have usable usernames/passwords, password re-use may get you a long way.
Back to how this affects you, as you only have trust to protect you with third parties, long passwords and avoiding password re-use are the only real options for avoiding a password compromise on one service spreading to other services that you use.
True, but if you're relying on that fact to keep your hashed password hashed then you're likely to be disappointed. Whilst modern crytographic hashing algorithms are designed to be computationally expensive, compute time is cheap.
For example, my password cracking rig (an old and slow box) can attack bcrypt hashes at about 1/10 the rate it can attack md5 hashes. So a 7-character password could be exhaustively checked in days rather than hours.
Go to https://github.com/dspinellis/unix-history-repo
Continuous Unix commit history from 1970 until today
[...]
The files appear to be added in the repository in chronological order according to their modification time, and large parts of the source code have been attributed to their actual authors. Commands like git blame and git log produce the expected results.
awesome
Years ago, I realized that memorizing a password was a pain in the ass while memorizing command strings was second nature. So, for the most part, my passwords are based on unix commands. So like my passwords would look like:
"mv /var/log/secure.0 /mnt/Filer01/home/logs/$(hostname)/" or "chmod 644 /var/log/Postfix/auth.log.bz2"
A command I typed on a nearly daily basis, many characters long, complete with numbers symbols, upper and lower case. I could even write it down on a piece of paper, or accidentally type it into a chat session and no one would even suspect it was my password. As a hint to myself, I might write down just the last part of the command. Periodically, I'd hack random characters into chats and instruct everyone to ignore it, or write something like that on a sticky note, just to throw people off.
So I thank ken for creating Unix and giving me something to base my passwords on (And also for all the benefits that Unix brought to the world). But also for having a password that reaffirms my strategy: Something he likely typed in -a lot- or wouldn't stand out from his normal typing.
You shouldn't even type that here, it's a brain worm. I was slapping away at a Sun when a young developer in the open plan office confessed happily to everyone in ear shot that he'd previously deleted his machine. I thought, what an idiot. Then he said, "Oh no, I've done it again", and I thought what a moron.
And then I did it myself. When you are coding, and someone inserts a thought into your code, well, I dislike open plan offices. Coders should have sound proofed booths.
It's kinda hard to focus when the background noise exceeds 90 dB. That and the occasional point-blank shouts straight to your ear. The only kind of person who can ignore such a level of noise would be DEAF. And even they will have trouble when the murmur reaches the low frequencies that are more felt than heard, approaching Brown Note territory.
"And then I did it myself. "
Many years ago:
In a crowded terminal room - someone interrupted me as I was typing a file erase command. On resuming I hit send - then realised in horror that I hadn't completed the command line beyond the directory name.
Apparently someone had also done that with a major statistics application source directory - which had not been archived owing to an ongoing system problem. They had to retype it from printer listings. In the process they discovered several bugs that affected the validity of the application's previous results.
Many years ago, late one night, I was working on a make file. Tired, I used a path something like '~/temp' in the make file. Ran make, then did an ls. I noticed that there was a directory called '~' in the directory that I was building in. So, figuring out that '~' isn't automatically expanded in make files, I rectified the mistake and then, to get rid of the mistakenly created directory I typed: 'rm -rf ~', and hit enter.
It seemed strange that it was taking so long to delete a few temporary build artifacts. A few minutes later (remember that I was very tired), the command was still running. A couple of minutes after that, I realised what I'd done. Just about to Ctrl-C, and the command finished.
On the other hand, I taught myself an 8 letter utterly random password and it keeps still working, no chess, no meaning, nuttin. Humans can remember 8 characters (latin alpha, upper plus lower, digits, no need to add spurious extra non-EBCDIC characters, whatever). Machines canne guess them, sorry capt'n, we donna have the CUDA cores, or the whisky, whatever.
Not as easy when you have to remember 80-odd of them (I have 86 random passwords stored in my password manager) and 8 characters is pretty short now.
That said my usual home desktop user password is 7 characters because I cba to keep typing a long one all the time... whoops.
My new one is 23 characters, and I'm in the process of switching...
My Linux account password may or may not be on the short side, and for the same reason, but the passphrase to unlock my LUKS encrypted SSD might be in the teens of digits (with both being random strings to which I have applied a mnemonic to remember).
This post has been deleted by its author
"A command I typed on a nearly daily basis, many characters long, complete with numbers symbols, upper and lower case. I could even write it down on a piece of paper, or accidentally type it into a chat session and no one would even suspect it was my password."
That depends on who sees it. Folk like us could be deceived but there are plenty of people who might see that on your desk, think it makes no sense and start wondering whether it's a password.
In this day and age, with vast computational power and cheap storage, why hasn't someone created a database of all possible password (up to say, 64 characters) and put next to them the md5, sha356 etc hashes.That way, you search for the md5 hash and find all the possible plain text passwords. I know some people would use it for evil, but I'm sure it'd be more helpful for sysadmins etc.
D*mmit - the NTLM mentioned several time here is DOS / Win3.x / Win98 time.
Server 2008 (non R2) and Vista were the last which Win98 and DOS could contact over the network, albeit needing a few modifications on the servers to be let in. Window Server 2008 R2 it was still possible as well, but required A LOT more effort, and a non-2008-R2 active directory if you needed that. With Server 2012 on: No dice, every old crypto shit of those old OS-es is blocked, especially in AD environments. To all those "Windows NTLM" screamers out there: Update your brain to spec and stop referring to Win OS-es older than two decades.
Unless you do the same for every old OS version out there, which will make you run away screaming from every computer.
You want to store a rainbow table of up to sixty four characters? Well, among other things, that's:
94^64+94^63+94^62+...+94 = ~1.926*10^126 password options (using the 94 characters from the standard ASCII printables)
Assuming we store a compressed version of that string that takes, on average, 20 bytes and we also store only a 256-bit hash (32 bytes), that's
1.926*10^126 passwords * 52 bytes/password * 1 terabyte / 1099511627776 bytes =
9.112*10^115 terabytes of storage
Using the rough numbers of 600 grams for a 3.5-inch hard drive, which we assume stores 16 terabytes, and has a cost of $200 U.S., this would produce a set of hard drives weighing 3.417*10^114 kg and costing $1.139*10^117.
In other words, your rainbow table would weigh about 1*10^75 times the mass of the sun and would cost so much that, even if you diverted the gross world product to pay for it, you'd need to continue long past the death of that sun to pay it off.
And that is why password hashes work at all.
If it was as simple as just "making every combination" and storing it somewhere, people would have done it decades ago.
Next question - how many ways can you organise/shuffle a standard 52-card pack of cards? Just a bog-standard pack of cards.
Now: How long do you think it would take to make every possible set of cards if you just sat and did it deliberately? Hint: You're going to need to start reproducing at some incredibly rate to provide helpers, and even then it'll likely take you millions of years.
Have a look at http://project-rainbowcrack.com/table.htm
A rainbow table for MD5, for instance, for all the easily-typable ASCII characters, for passwords up to length 7 is 27 GB.
A rainbow table for length 10, but only alphanumeric characters, is hundreds of gigabytes.
From there, it explodes out of hand very quickly.
There's a reason we tell you to use passwords greater than 8 characters. And I'll let you into a secret... no matter what your wife says, only length matters. All the complex characters etc. do almost nothing to increase the difficulty. But adding one single character to the length can multiply the complexity by orders of magnitude immediately.
How long do you think it would take to make every possible set of cards if you just sat and did it deliberately?
That reminds me of something I read a while back that puts it in perspective:
"Say that there exists 10 Billion people on every planet, 1 Billion planets in every solar system, 200 Billion solar systems in every galaxy, and 500 Billion galaxies in the universe. If every single person on every planet has been shuffling decks of cards completely at random at 1 Million shuffles per second since the BEGINNING OF TIME, every possible deck combination would still yet to have been "shuffled"."
52! = 8.06e+67 (roughly)
We have 10e+9 * 1e+9 * 200e+9 * 500e+9 = 1e+42 people on the job
Each checks a million a second, so we're going through 1e+48 combos/second
It ought to take about 8.06e+19 seconds
There are about pi * 1e+7 seconds in a year, so about 2.56e+12 years
The universe is about 13.8 billion years old, so we'd be about 0.5% done.
I started this out thinking I might show you were wrong. Obviously, we're _way_ behind on the job... time to start populating the universe, building lots of playing card factories, and practicing our shuffling skills.
... no matter what your wife says, only length matters. All the complex characters etc. do almost nothing to increase the difficulty. But adding one single character to the length can multiply the complexity by orders of magnitude immediately.
Good advice, but why do people always refer to the the number of characters in a password as its length? On my screen it's quite clearly width.
There's a reason we tell you to use passwords greater than 8 characters. And I'll let you into a secret... no matter what your wife says, only length matters.
Well, yes and no.
Dictionary tables, containing a few thousand different common words, and an algorithm that subsitutes '1's for 'i's, '0's for 'O's etc. in all available combinations, adding in common combinations of numbers and symbols before and/or after the word can crack many passwords pretty quickly, even if the word they are based on is "flocinocinauhinipilification".
I'm no security expert, but to take a keen interest in such matters. IIRC, the general approach to cracking an a file of unknown password hashes (lets say we have 10,000) would be:
1) Check against a list of "top 1000" most common passwords - this will probably get you 85% of them in a few seconds.
2) Perform a dictionary attack on unsubsituted words (and common anmes / phrases) - probably get you another couple of %, in a few minutes, depending on the password policy in use (i.e. no "must contain a funny character / number" rules)
3) Perform a dictionary attack with substitutions; this will probably get you another 10%, perhaps in minutes/hours
4) If the hashes are unsalted, you can use a rainbow table. Depending on the amount of space you have, this will crack all passords up to however many characters you have the table for (lets say 8) in the time it takes to seek the index (fractions of a second per password). (this is why we salt passwords)
5) Brute force the remaining 5% (lets say we have 500 left). Depending on the length, and the hardware you have available, this is going to take anything from minutes (passwords of fewer than 8 characters) to months (passwords of ~12 characters) to years (more than that) for each password.
As you can see, length is important if you want to protect against an attacker brute-forcing a password, but at the same time, not choosing an obvious password (such as "Password123" or "Correct Horse Battery Staple" or "ManUnited4Ever") is more important, especially since attackers will typically go for low-hanging fruit. If you set weak passwords for things, you're also more likely to re-use those passwords, and potentially be an easier target for things like phishing as well.
Sorry, but that calculation is not sufficient. You're getting the combinations of 64 characters that can come from a set of 94 possibles. But since characters can be repeated, there are actually 94^64 options. However, since a 63-character password is not one of the set of 64-character passwords, it becomes that series I wrote instead. Either way, it's a bunch of numbers. But just in case you have access to the biggest hard drive and processor factory ever, make sure you check all permutations and all lengths lower than your limit or your rainbow table will have gaps.
This post has been deleted by its author
So, that's 700Gb for hashes of all passwords up to 9 characters in length (The size of a standrard hard disk), 94x that size, for 10 characters (66 Terabytes, the size of a large comms room disk array), 94x that size for 11 characters (6.2Pb, the size of a pretty big data centre), 94x that for 12 characters (580Pb, about twice the size of CERN's data centre storage) ... (64! - 9!) x 94 that size for 64 characters (we're going to need a bigger multiverse).
"In this day and age, with vast computational power and cheap storage, why hasn't someone created a database of all possible password (up to say, 64 characters) and put next to them the md5, sha356 etc hashes.That way, you search for the md5 hash and find all the possible plain text passwords. I know some people would use it for evil, but I'm sure it'd be more helpful for sysadmins etc."
Indeed... and then why havn't we created the same tables with every conceivable salt applied to the inputs?
I think we might run into storage problems....
"But given that Thompson's eight character password hash was cracked in a few days,....."
On modern hardware, using modern algorythms.... I very much doubt that anything they had in the day could have brute-forced that password in any time within a human lifetime. (And remembering the extortive rates for run time in the day, you'd need the budget of a moderately-sized industrialised nation to even try...).
"I very much doubt that anything they had in the day could have brute-forced that password in any time within a human lifetime."
It depends which day. The Cuckoo's Egg by Cliff Stoll is an interesting read. I can't remember the period to which it relates but I think it was the 386 era. Someone had hacked into a system he looked after and he discovered they'd copied the passwd file. In those days passwd contained actual passwords. They came back a few days later using some cracked passwords.
The passwd file needs to be universally readable so that programs can look up the owner name of a file from its numerical owner, e.g. ls -l That's why we don't now have passwords in passwd but in shadow.
"The passwd file needs to be universally readable" hold it hold it...
Never heard of /etc/shadow ? So you are about 30 years behind. THIRTY YEARS!
From https://en.wikipedia.org/wiki/Passwd#Shadow_file
Password shadowing first appeared in Unix systems with the development of SunOS in the mid-1980s, System V Release 3.2 in 1988 and BSD4.3 Reno in 1990.
Exactly... that password has been "in the open" since 1979 in one way or another, certainly exposed, and certainly since 2014 it's been known about.
The effort to crack such things is intense even today, and takes someone specifically looking at decrypting EXACTLY that old, decrepit hash, just for fun. They did quite well, considering. And in any live system, that password would have gone through dozens of hash updates and upgrades. It didn't do bad for something that was probably written before I was born!
" I very much doubt that anything they had in the day could have brute-forced that password in any time within a human lifetime"
Well, the fact that it has been cracked within a human lifetime demonstrates that you are incorrect - the research they had in the day led directly to the GPU that eventually took just a few days.
Forward secrecy is hard... Although to be honest having a password that took this long to crack was quite good... The character combination would certainly have been unusual, and it was easily memorable.
> " I very much doubt that anything they had in the day could have brute-forced that password in any time within a human lifetime"
> Well, the fact that it has been cracked within a human lifetime demonstrates that you are incorrect - the research they had in the day led directly to the GPU that eventually took just a few days.
The original poster was talking about cracking the password using the hardware which was available at the time this password was leaked. I.e. 1979.
That's 40 years ago. Let's see - where's that beer mat?
*scribble*
Applying Moore's Law, that's about 25 cycles of exponential performance improvements. I.e. today it took 4 days, but 18 months ago it would have taken 8.
And 4^25 days is a number big enough that Google's built in calculator switches to e notation (1.1258999e+15, fact fans). But with a bit of tinkering, it comes to 3,084,657,279,020,000 *years*, if you had attempted to brute force the password with 1979 technology. Cry havoc and set loose the Apple ][!
Yes, it's a gross oversimplification - Moore's Law hasn't really applied for a few years, this was done on consumer GPU hardware, and no doubt there was special hardware and algorithms clutched firmly in the claws of various secret agencies, even then. But hey. There ain't that much room to scribble on this beer mat...
"Applying Moore's Law, that's about 25 cycles of exponential performance improvements. I.e. today it took 4 days, but 18 months ago it would have taken 8."
That's pretty good. The fastest hashing AMD GPU 18 months ago was an R9 390x with half the hash rate of the VEGA which came out about then. VEGA also uses about half the power to work twice as fast.
There are farms of these VEGA cards mining crypto. Even a 4 card rig could probably do it in a day.
It's an interesting point of semantics, the hardware available in 1979 has been used to create the next generation of hardware, and then the next generation of hardware and then...
Ultimately they used a better algorithm than straightforward brute-forcing, which was to build better technology first and apply that.
There's a real lesson though, don't judge the expected lifetime of your security measures against today's hardware. If in 1979 Ken Thompson had relied on his password being secure past 2019 based on what brute-forcing with then-available technology could do he would now be out of luck.
Kinda surprised nobody's pointed this out : Moore's Law posits a _doubling_ of computing power every 18 months. You've got it as a _quadrupling_; it's 2^25, not 4^25. You also have it as 25 quadruplings times nothing in particular, rather than 25 quadruplings starting from four days.
So we really ought to be thinking that 40 years ago, it would have taken about 4(2^25) days to crack this password, or about 370,000 years. Still a long time, I grant you. But not 200,000 times the age of the universe.
> Kinda surprised nobody's pointed this out : Moore's Law posits a _doubling_ of computing power every 18 months. You've got it as a _quadrupling_; it's 2^25, not 4^25. You also have it as 25 quadruplings times nothing in particular, rather than 25 quadruplings starting from four days
Fair point - I should have paid more attention when scribbling on the beer mat ;)
One of the best methods of optimising HPC tasks for decades has been to "buy next years computer instead".
This is a (slightly protracted) version of that.
The low interest (given that it only took a few hours on current hardware - it would only have taken a few days for the last few years) is what kept the secret for 40 years - the early leak, and the fact that it resisted (niche) efforts for even a small number of years is still impressive - but does also show that password entropy is really important.
Forward secrecy is really hard - how long you want something to remain secret depends on how disposable it is... If it's a login that you can revoke and set a new token then it only needs to be reasonable.
If it's protecting a file which you speculate might be released in it's encrypted form (i.e. you don't trust your cleaners, or it must be transmitted across non owned networks) then you might want it secret for a lot longer than 40 years... and that becomes very difficult indeed.
But even then you have to get hold of the passwd file to do even that.
In this century you would need the shadow password file which requires root access, and, a rainbow file would not help as a random “salt” is added to the password before encryption.
The biggest problem is complex password rules which demand a mixture of lower and upper case plus a number and a special character, which requires a post it note to remember.
A minimum of 12 any character you choose would provide better security.
Interestingly enough, when they looked at DES before it was released, they suggested changes to the S-boxes used.
Those changes made little sense at the time, but were implemented.
It was about 20 years later when differential cryptanalysis techniques first surfaced in a research paper, it was found that these changes made it far more resistant to this type of attack.
Which of course means they knew about differential cryptanalysis back then.
Give with one hand, take with another I guess.
No capital letters.
On second thoughts, I imagine the iterations over character classes goes lc, digits, uc, symbols, based on common usage patterns. So you can probably still get the complexity benefits for brute-force resistance of uppercase letters even if you don't actually include them, but still use symbols. The uc letters will be checked anyway, but more symbols puts the check of your password at the back of the list; brute forcing "aaaaaaaa" must be pretty fast, but ";;;;;;;;" slow.
Even massively parallel brute-force searches have to run through the search space in a certain order. Not all at once.
I'm counting on the guess that 'aaaaaaaa' will be checked really early, long before ';;;;;;;;', which I'd expect to be later, at least for combinations of that length. That is unless the algorithm checks repetitive combinations before pseudorandom ones, which would be a good idea.
Genuine question: Apparently having series of the same letter ("aaaa") in a password is a bad idea, isn't it? So what about that same series of letters appearing mixed with other letters, like "a+a#a%a"?
My point being that "a+a#a%a" is pretty similar to "aaaa+#%", which apparently is supposed to be a bad password. Many passwords (especially long ones) have repeating letters, do those reduce entropy? And if not, why is "2Tz~K£aaaa" a worse password than "2Tz~K£qwhu" (no repeating letters)?
.
(Just wondering, I like to understand.)
Kinda?
A 'true' brute force tries literally every combination until it hits one. These don't care about repeated characters at all.
Cleverer solutions try to focus on "most likely" strings. Lists of common passwords, dictionary words with a number at the end or the standard vowel replacements (i=1, e=3, etc), and easily memorised patterns.
If your repeated letters drop you into one of the Known Patterns, it'll be cracked sooner, though odds are very good it won't. In reality, the person setting the password rules is going on gut feel and trying to stop users doing daft things like making their password "aaaaaaa1!", and implementing rules they think will help.
Then the original coder leaves the company and no-one else knows why these rules were picked, so they all assume there's a good reason...
Sure, but simply going by the password cracking tools, is "password%%%%" easier to crack than "password#%$&"? All right, the "password" part is a common dictionary word, but what I'm wondering is if the four characters added to it will/should/might obfuscate the hash so the cracker needs to brute force the whole thing like if it was all random. And in this case, would be "password####" really easier to crack than "password#%$&"?
The idea is to defend yourself against what will attack you, so if it's all the same for password crackers, you could possibly use a password like "password++++++++++++++++++++++++", which is 32 characters long and yet very easy to remember ("password" and 24x "+"). All right, I admit that from a purely theoretical point of view it has less entropy than a 32-character password like "nB!y8s#ey8$aw&I1ga2x?t3-6+86K=OA", but is its hash really easier to crack? I don't think you could find that in rainbow tables, I think that calculating the hash of any dictionary word with a random amount of a random number of repeated characters after it would create a unmanageably huge list, which puts you beyond the reach of ordinary (lazy) hackers (obviously if your password protects the crown jewels you might want to go the hard way and avoid that kind of cheat.)
Arrived here late. If anyone is still reading...
Suppose I put batteryhorsestaple in a Playfair like grid of (say) 5 by 4 squares like this
batte
ryhor
sesta
pleXX
and then read the grid top to bottom in columns giving
brspayelthsetotXeraX
have I just defeated the probability based crack strategy and dropped down to brute forcing a 20 character passphrase? Or do the crack algorithms look at permutations like this?
> do the crack algorithms look at permutations like this
I don't know, but I seriously doubt it. It's about the exponentially increasing amount of possibilities: You chose a 5x4 grid, but you could as well have chosen a 4x5 one, or a 3x4 (and so on). At some point it becomes impractical to try to find any hidden dictionary words and you just brute force the whole thing.
Some permutations are obvious, "password" can be "PaSsWoRd" or "p455w0rd" (and so on), so it's easy to check for those as just as many new dictionary words, But then there are the less obvious modifications. For instance ROT-13 might be count as obvious, but what about ROT-[my first girlfriend's birthday divided by my car's license plate]? Too many possibilities to check for, so for all intents and purposes it's a totally random string.
Thanks.
So there is a point in making passwords you can't/don't want to write down (at that time) insanely long, by adding a rather big amount amount of repeated characters. It's very easy to remember "my parents' names and 58 times the symbol '§'", or even better, "17 times '@', my parents' names, then 41 times '§'".
Even if the adversary knows you might be using such a scheme, due to the huge size of the final password I guess it must take quite some time to crack, especially if you put the dictionary word(s) somewhere in the middle of the repetition, forcing the adversary to check all possibilities one by one.
Just an idea.
It can be tuned (the John the Ripper file is interesting enough that it looks like a beginner's sendmail.cf), but it's usual to start with words (and word transformations). When it comes to brute-forcing, I suspect that it's based on frequency analysis of cracked passwords.
One thing I always point out in reference to word transformations when someone suggests one, is that professional password crackers have already thought of every transformation that we've thought of, and then some.
I was wondering the same thing... It could be that early unix only accepted lower case and standard symbols. Putting in something like the BEL character (Ascii #7) is decidedly uncommon.
the word "somehow" is suggestive that it wasn't usually possible.
https://retrocomputing.stackexchange.com/questions/12523/could-you-use-uppercase-or-special-characters-in-a-password-in-early-unix
I was wondering the same thing... It could be that early unix only accepted lower case and standard symbols. Putting in something like the BEL character (Ascii #7) is decidedly uncommon.
I did once try creating a password with a BEL (Ctrl+G) in it, on a Westrex teletype connected to a mainframe. The distinctive ding of the teletype's bell when the password was entered was a dead give-away for anybody watching one type it in!
Not recommended.
In one job I spent most of my time on other companies sites surrounded by their employees, often with another colleague at the other end of the room. We so often had to pass passwords that a developer came up with a shared code based on song titles that we could whistle to each other without anyone realising.
It was obviously a flawed system given not everyone could whistle and didn't share common songs always, but I'd just moved there from a council where the way to find out the sys admin password was to shout across a crowded room, "What's the password?" and they'd shout it back.
To this day all my unimportant pass phrases can be whistled, just out of nostalgia. I think the tune is an aide-mémoire.
Interdimensional travel through interpretative dance is the plot of the surprisingly good "The OA".
A woman trying to chat me up once said I was very graceful, and asked what forms of dance I did. I blew my chances by telling her I didn't ever dance. Idiot, she wasn't actually asking me to dance, I could easily have lied and said foxtrot or something.
Aye, they should have either cancelled it after the first season or commissioned it for a third season.
The first season was excellent though, far better than Stranger Things or Dark. Each episode was so tangential yet cumulative and substantial.
The opening sequence of the main protagonist jumping off a bridge to kill herself was defining of the concept.
This post has been deleted by its author
I worked with a VAX 11/780 with the VMS operating system around 1980. Passwords were hashed to a 16bit word. The interesting thing was it used the same password algorithm as the Radio Shack Model 1 computer. It was a simple matter on either system to go into debug and change the password hash to a null password.
As always the answer is "It depends"
If the person trying to crack the PW knows that its 6 random short words then they can factor that into their attempts at cracking the password which reduces the amount of possible combinations considerably.
If they don't know anything about the password they are cracking and they need to brute force it using random combinations of letters six short words is considerably safer than eight random characters (Easier for a human to remember too - so less likely to be written down).
Factor in a decent salt and I wouldn't have too many concerns about this at all.
Many of the passwords I have to anything important are made up of words or short phrases.. if you're really paranoid misspell one of the words...
Its never going to be un-crackable (As the article demonstrates, over a sufficient amount of time, nothing is) but you're definitely into the realms of it being unfeasible for the foreseeable future.
My ISP assigns passwords - with no option to make your own strings. They use a random combination of about six short-ish words. How effective is a brute force approach for guessing those?
Is this RFC2289? That, as written, uses six words from a dictionary of 2048 to represent six groups of 11 bits that encode a 64-bit number (with a bit of juggling to get 66 bits from 64).
If so, there are 2^66 possible different combinations of words, of which only 2^64 are actually used.
RFC2289 is quite old, now. It describes using MD4, MD5, or SHA-1 digest algorithms in a password generation function. Given the general weakness of passwords I would think that RFC2289 with SHA-1 would still be regarded as better than a user-chosen password, but one could update the algorithm to use a better hash function -- but then one would probably want to use more than 64 bits of the digest output, and so would end up with more than six words in the password.
"[...] uses six words from a dictionary of 2048 [...]"
Presumably the set of 20148 words are chosen by each implementation - rather than being prescribed by the RFC?
Without access to the details of that "unique" set then cracking it has to assume a much larger dictionary of possibilities. However - a subscriber could repeatedly request new passwords and thus map the permissible set to some extent.
"I remember being able to use a Linux boot CD to either reveal or set new Windows XP passwords in a few minutes."
One of the first lessons I learned as a junior systems programmer many, many years ago To get past an O/S's security - treat its filestore as data for an unrelated O/S.
There is so much wrong with all the "current" password guidance out there. First, the PHB types don't bother to check the timestamp presenting generation(s) old guidance as current. Then you have the lazy dev types only implementing the minimums but leaving out select special characters because their input checking is non-existent and have to avoid SQL injection, but technically current guidance. All the stupid rules only allowing this, disallowing that. So I type "WTF?RuStup1d!?" only to be presented with password too long, getting my answer. You gotta love those password strength gauges, a strong password in as little as six characters. There's too many chefs in the kitchen, the good password guidance soup is overloaded with ingredients; it is both watered down and over spiced at the same time with no real substance. But hey, it's an acquired taste.
Because Ken confirmed it. (Or appeared to.)
Otherwise, being pedantic, they wouldn't know they had arrived at the original password. All they'd know is they've found a string that produces the original stored hash. Though, as that's all you need to get past a log-in mechanism that's checking against that hash, you can consider it cracked.
8 character passwords are no longer recommended and have not been for a couple years now because of the ease with which they are compromised as the latest demonstraton shows.
Content does not matter, even special characters have negligible benefits in a hash this short these days.
Use pass phrases where your admins allow.
Pass phrases are snippets of something that you can remember that make a sentence or nearly a sentence.
A good one had I not just used it on a public forum would be something like:
Don't panic and remember to bring your towel.
That is 42 characters long and won't be crackable until quantum computers are available over the next decade or so.
It is also very easy to remember and not really all that slow to type.
And it is secure, for now.
Pass phrases people: use them, love them, be secure.
Though, if it's a direct quote from a book it will potentially be prioritised in brute forcing over more random phrases.
Part of the intent behind "correcthorsebatterystaple" is that the words should be selected randomly, the process XKCD is referring to is called dice passwords and the real intent there is you have a fairly large table of words and select them using dice (which can be done without a computer or relying on computed random numbers, meaning the entropy is as guaranteed as it ever can be). There are other similar schemes and recommendations that don't have the dice component.
The space of phrases available in all published books is still pretty big, and you can add a few more bits of entropy by adding some random transformations to them, but the space of all possible combinations of fairly short sequences of words in any language rapidly becomes far greater.
"I'm still looking for a solution compatible with no extra software AND very bad (say geriatric) memory."
There comes a time when you just need a small black book and a pen. Then you can do things like take the first two letters of each word in a text, or use a Playfair type grid &c.
https://www.schneier.com/blog/archives/2014/03/choosing_secure_1.html
Coat: mine's the one with the All Weather Notebook in the pocket
VERY bad memory cannot be solved with mnemonics; they forget the mnemonics. In this case, they'll lose track of which two letters or not figure out how they set up their grid. Or they could just lose the book like they do their car keys or phone every other day (and forget it, they're too proud to ask for help).
Thompson, who helped create Unix and the Go programming language among many other accomplishments, acknowledged the feat by offering his congratulations. He didn't immediately respond to a request for comment.
so, if the man himself was still around, why not just ask him, and save all this palaver :o)
just call it social engineering if you were to write it up of course
We always knew DES encryption had a backdoor and was intended to be cracked. The U. of Waterloo proved that many decades ago.
Having the secure file of hashed passwords has always been known as being reversible.
There is never going to be a way of preventing that.
That is because you do not have to get the right password.
All you need is to end up with the same hashed result.
And that is never computationally hard, just slow.
Having the secure file of hashed passwords has always been known as being reversible.
There is never going to be a way of preventing that.
That is because you do not have to get the right password.
Going to be a bit pedantic: actually your third sentence here means the first one is not true. If hash collisions are possible then the hash isn't reversible. Of course, that's not the challenge in cracking passwords, the possibility of exact collisions doesn't really make it much easier to attack a hash (unless you're using passwords with a lot more entropy than the hash can store).
I've been using an 8 character password for almost 20yrs and so it's never been hacked... However, for the last few years I've retired the variations of that one and switched to a new formula. 2 words and a minimum of 4 digits that is linked in some random way to the site I am using it for.
That means on average my passwords are now 15-20 characters, both upper/lower case and numerical.
So for example... say you've got an account on a food site where you get recipe's and nutritional advice.... a password could be GrandmothersCupcakes1975.
I've found that to be far more effective and efficient that creating random passwords It also doesn't hurt to write them down at home because the chances of anyone breaking into my home and searching for tiny little notebook the size of a credit card just to access my account on some random website is pretty non existent.
"[...] nobody has said what p/q2-q4! means"
The Q2 and Q4 are unique identifiers of squares on the board matrix. Where 'Q' is the Queen's column (file) - and the numeric is the row (rank) starting at 1 for presumably White's back row. The ! is presumably an "end of sequence" marker?
A fairly standard opening gambit. You are moving your Pawn in front of your Queen forward by its permitted two rows in a straight line.
Here is an insight into the complexity that has to be encoded.
The aforementioned link points to the kind of notation I'm more familiar with (from the days when the Chessmaster was en vogue). This password appears to use a different kind of notation, as files are normally a simple a-h instead of using piece notation (which can get confusing due to there being more than one bishop, knight, and rook file), slashes aren't used (except in some variants to indicate a promotion), the pawn is normally indicated by a lack of a piece tag, and the ! is normally reserved for noteworthy moves.
No, those are britches. The breech is what you stick in your britches and where the crap comes from (in biological sense, the breech is your butt; in artillery sense, the breech is the back of the gun barrel--think breech-loading). As for a breach, it's normally considered militarily or architecturally: both in a bad way, as it usually means a break in some kind of line or fortification (think hull breach).
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
