Hacker News new | past | comments | ask | show | jobs | submit login

I'm shocked at how well the old hashing stood up; sure, it's totally crackable today, but a well-picked password still took 4+ days to crack on modern hardware, which is remarkable. (Granted, it doesn't sound like they did anything fancy like throwing a hundred cloud instances at it or something; I'm not saying you should use DES today:) )





30 years ago I cracked everyone’s Unix password on an old Sun computer.

It didn’t take long because everyone had a password that was in the dictionary.

Needless to say, people were not happy with the messenger.


Inherited a system at current (for a few more weeks) employer (recently written so no excuse) that had used a weak hash for the password, I pointed out to my boss how bad it was and that it shouldn't have happened, he didn't pay a great deal of attention.

So I threw the OpenMP variant of John the Ripper at it (I'd just built a 8C/16T Ryzen machine and was curious) it broke ~80% of the passwords in under an hour and all of them over an afternoon of not been in use.

Went to see the boss and gave him the list of passwords including his (which was one of the weaker ones) - he gave me the time to fix it and some other glaring security issues.

The more things change the more they stay the same.

I know enough about security to know that I really don't know about security.


Reminds me of a security issue we had on our linux servers at a former employer. Short of it is, one could run any command as another non-root user without having sudo access or knowing the user's password. rsh access was inadvertently left wide open on thousands of servers.

A coworker and I stumbled into this one morning when I was helping him figure out how to remotely invoke a linux command from a windows gui. I don't recall why we were using rsh as we'd normally ssh into our servers. As we sat there trying to figure out how to enter the password, we decided to just try and run the command w/o a password. We were shocked when it just worked - we were never prompted for a password. When I reported this to my director, he asked me how bad it was. I was like, watch this: I sent an email as the CEO to him saying "you're fired.". He immediately went to our infrastructure team to get it fixed. Fun times...


> I know enough about security to know that I really don't know about security.

I'm not sure anyone ever gets past this point. There's way too much for any person to know and not enough hours in a day or days in a year or years in a lifetime to master everything. Even when it comes to computers in general at some level it just becomes magic to me. I might be able to point to a chip and say "that's the sound chip" or "that's a math co-processor", and even write software for it, but I have no idea what goes on inside and I wouldn't know where to even start trying to build one from scratch.


That’s my feeling as well, I try to follow best practices at the level I work at and hope everyone on the levels below me did the same.

Had I done this to any of my bosses I'd have been fired

That's funny - I was going to post that I was first exposed to this thirty years ago when my password was cracked on an old Sun computer! I didn't complain, it was a wake up call. (You weren't at OUCS were you?)

Ah, I remember doing that. Not quite 30 years ago, but jeez, getting close. Funny, it helped me remember some of the professor's wives names, and for some reason I can remember the husband-hunting Italian lady's password (amici) while I've forgotten both her name, her thesis project and everything else about her.

It was actually decently well received by the department head; he sent out a memo to the staff to not use their wives names for emails and looked like an early computer security innovator in the physics department.


30 years ago you could just sniff the passwords on the local subnet because everyone was using telnet and ftp in the clear.

20 years ago you could also sniff passwords for all Windows users in the same subnet as you. Windows used the NTLM scheme which was known to be weak even back then. An AMD K6 running overnight cracked almost all of them at my university's lab, including the Active Directory domain admin.

An NT hash can be used as a credential all by itself, no need to crack those ;)

You can't really blame them... it was called a pass "word".

I got myself and my best friend in high school fired from a fairly good gig because I cracked some dumb passwords and a CEO took it the wrong way. I still don't think he fully forgave me for it.

No good deed goes unpunished.

More specifically, pointing out someone else's stupidity is rarely welcome.

I had both experiences in high school. One situation -> bad result. The other I was made a quasi IT fixer - they put me to work (Novel Netware and other stuff). I would be called out of class to fix things. Since I was naturally super interested in how everything worked together and all the features and the librarians or VP or teachers were not it worked out. At the time I took it reasonably seriously.

In hindsight some teacher must have spoken up for me to come up with the solution when they were trying to come up with an appropriate response.


Novell Netware - blast from the past.

I had to go apologise to IT (who could barely keep a straight face) at college for sending a message from 'God' saying "I saw what you did last night and it disgusted me".

I thought it was going to just the lab but since I was poking around in something I really didn't understand I manage to send it out site wide.

Fortunately they saw the funny side.


I sent more than one message from God by telnet to <mail server> 25. Good times!

Around the same time, someone at my school made a much, much worse semi-accidental prank. Semi-accidental because he didn't think it would work. See, the campus list serve was setup to only allow certain senders to send messages. Makes sense, only a few top administrators should be able to do that. This person theorized that a simple <smtp: from> hack, using an authorized person's email, might circumvent the restriction. He was right! Unfortunately, rather than "test 1 2 3" or something, he sent a message, from the president, that all classes had been cancelled. Had he stopped there, maybe it would have been chalked up to a prank. But he went further: The president would be using this free time to, um, entertain amorous visitors at their leisure. So, yeah, expelled. His excuse, when interviewed by the student newspaper, was "I didn't think it would work."


I send unauthenticated email on port 25, every semester, in front of my students, as part of a discussion on internet application protocols. I can't use "God", because the addresses are validated, but I do send "from" the school's IT director. I even give them the commands to do it themselves (along with a strict talking to about how it's not truly anonymous because their network access is authenticated).

I've been able to do it at every university I've studied or worked at.


Many, many years ago when I was in college at the University of Rochester, I found a paper in the computing lab with the root passwords for about twelve machines at Stanford. I emailed them and told them I'd destroyed it but that they should be much more careful. I got yelled at.

Just curious, did you get yelled at because you destroyed the only copy of their password memory aid? ;)

If they were keeping their only copy at an unrelated University thousands of miles away, they had more problems than I thought ;)

I'm actually not sure anymore what the details of their return email was, as it was over 25 years ago. But it was basically, "We will report you to law enforcement if you contact us again."


They must've been really embarrassed to send that kind of response.

This must have been a popular pastime in the 90s as I did the same thing for my university's security on their new, centralized student accounts server. This effort was further aided by there being a predictable salt used for the password hashes that indicated which passwords were still set to the (again, predictable) default pattern. They were kind not to kick me out and not fire me as I was both a student and part time employee in their networking services department.

25 years ago I didn't need to crack anyone's unix passwords- they were all broadcasting them in cleartext every few minutes because they were using eudora or some other mail client, and I had converted an old sun workstation I found into a packet sniffer.

I remember in middle school using "arena" as a password.

"No one will ever guess this!"


At my middle school the default password for all accounts was "linux". The school was Windows (Win2k) only ;) it was around 2006/2007) I had access to a dozent Teacher accounts from oder ones who never used a Computer.

Actually that was the first time that i heard the word Linux and learned the meaning just few years later.


> I'm shocked at how well the old hashing stood up; sure, it's totally crackable today, but a well-picked password still took 4+ days to crack on modern hardware, which is remarkable

It's not because the hash is strong, but the password itself is strong (if the attackers don't know additional information about chess). The sole purpose of using a strong <del>hash or a</del> KDF on password is making low-entropy passphrase harder to crack by increasing the cost of every round, especially for cryptographic purposes. But if the passphrase is already strong (6 random words from the Diceware wordlist), you can use MD5, and I won't be surprised if it takes one year to crack. Having 10 random words is guaranteed to be uncrackable under all circumstances, because it's literally a 128-bit key.

If your password has 80-bit of entropy, it makes even listing all possible passwords (without any hashing or encryption) a difficult job. Symmetric encryption works in a similar way, it's secure not because of the computational resources it takes, but the number of possible keys it has.

What is the moral of the story? Consider to use a password manager!


> But if the passphrase is already strong (6 random words from the Diceware wordlist), you can use MD5...

Is this actually true? Note that you don't need the actual password, just a hash collision.


MD5 is vulnerable to collision attacks, which allows the attacker to control both messages, m and m', and find a case where h(m) == h(m').

But if a hash, h(m), is given, finding m' where h(m) == h(m') is much more difficult, it's known as a second-preimage attack. "Image" basically means "output", "preimage" means "input", "second-preimage attack" means "find another input that has the same output already given here".

Wikipedia says a preimage attack against full MD5 still requires 2^123.4 steps (2009), only a theoretical possibility. Second-preimage should be much harder.

I don't know if there are improvements, but it's still extremely difficult. Well, of course it's not to say that you should use MD5.


A second-preimage attack is where you want to find m' where h(m) == h(m')... and you know m already. This is not very useful for password hashing; it would give you a second password that would also work to log into the account, but what's the point of that if you already know the first password? The relevant attack for password hashing is a regular preimage attack, where you don't know m (and it would be acceptable to find either m itself or any other string that hashes to the same value).

You don't need to know m, just h(m) which is commonly found in database breaches

That's just a "pre-image attack". A "second pre-image attack" is a different scenario, not relevant to password-hashing for the reasons grandparent described, where you already know a pre-image, and must find a different one.

It doesn't seem like it should be obviously true to me. If the hash algorithm was rot13 it would be pretty easy to determine the password from the hash regardless of the strength of the password

Yep, you need both the input and hash to be strong.

A weak hash reveals information about its input, narrowing the search space. In the example case of md5 or rot13, you can use this to compute collisions for a given hash.

Also, a hash that is lightning-quick to compute is faster to brute force. That's why bcrypt has a tunable "cost" factor - to make the hashing take longer and make guessing the password slower.


I used ambiguous language, "strong hash".

I should've used "strong KDF" rather than "strong hash", a hash can be strong for other purposes, but makes a poor KDF for hashing passwords, such as single-round SHA-256.

In the ideal world, if your password is a random word with 128-bit entropy, no strong KDF is needed, there's no need for PBKDF2, bcrypt, or Argon2, a single round of SHA-256 is sufficient.

> In the example case of md5 or rot13

MD5 still has strong preimage/second-preimage resistance, unlike ROT-13.

But nobody uses random 128-bit strings as passwords, here's how key stretching and cost-factor comes to play.


You could argue that ROT13 accidentally has second-preimage resistance because given m, you won't be able to find n≠m where ROT13(n)=ROT13(m). :-)

Some quick (and uninformed) mental maths makes this ~22 random alphanumeric characters:

26 (a-z) + 26 (A-Z) + 10 (0-9) = 62 characters This which can be represented with (just under) 6 bits of information. (2^6 = 64). And 128/6 < 132/6 = 22.

I'd guess quite a few people who use password managers use password this length...


Can ROT-13 really be called a hash though? It's literally an ancient chipher.

By the plain* meaning of "hash", it can't, it's a symmetric cipher.

* Where "plain" excludes a technical or mathematical definition that might include e.g. troll_hash(x) { return 9; }


All ciphers are also hashes.

Using chaining, encipherment of the last block is also a hash of the whole input.

Secure hashes are optimized for different characteristics than typical ciphers, but with enough headroom and time each can fill in for the other.

Of course some are not very good, for either use.


Rot13 is not a hashing algorithm. A hashing algorithm is a one-way function where many entities in the input domain map to the same entity in the output codomain. This means if you have the hash you can't determine the input with out making a guess.

Rot13 is a function with a one to one mapping between the domain and codomain. If you have the output you can apply a function to get the input.


Not sure why the downvotes. Comradesmith's assessment of rot13 is absolutely correct. Clearly rot13 is more like PGP, in that you can recover the plain text from cypher text.

But you don't care about finding the original password. You only care about finding a string that after applying the hash function, gives the same out.

That's why you can have a hash function like h(x) = 0, whose value gives you no information about x, and still not being able to use it.


Really it's because of a mixture of the two. The traditional DES-based crypt is basically a really early KDF - it was intentionally designed to be slow in order to thwart brute-forcing attacks. (Of course, since it was based on the speed of late-70s computers and had a limited password length, it's pretty feasable to brute force with modern hardware.)

MD5 wouldn't be invented for another decade or two...


And "Good news — no pwnage found!" On Troy Hunt's https://haveibeenpwned.com/Passwords

Which shows that it is fairly strongly "unique", since no-one else has used it and been pwned (or he hasn't reused it and been pwned).


I hope this site is not fishing for passwords ...

Its quite truthworthy. Its run by Troy Hunt (known security researcher) and : "When you search Pwned Passwords The Pwned Passwords feature searches previous data breaches for the presence of a user-provided password. The password is hashed client-side with the SHA-1 algorithm then only the first 5 characters of the hash are sent to HIBP per the Cloudflare k-anonymity implementation. HIBP never receives the original password nor enough information to discover what the original password was." from https://haveibeenpwned.com/Privacy

My only concern with the site is some privacy implications. I entered a friend's email just to check for him and it wasn't validated at all, and I found out a few sites he had accounts with. Nothing too concerning was revealed, but privacy for its own sake is a valid goal IMO.

As far as I know hibp specifically hides sensitive breaches (such as the Ashley Madison one) to non-verified access. Also, he basically only shows public data; your privacy was already gone back when the original company failed to secure their servers.

Understood, it's a small complaint, the data is already out there on the web and it's not his fault. But there is value in aggregation or the site wouldn't exist. It makes it easier to just put a few emails in there and see what shows up for fun or malice.

It's great that sensitive breaches are apparently hidden but I'd be wary of judging for other people what is sensitive. Some like Ashley Madison are obvious, others less so.


Are you gonna fire Troy?

Yes, of course.

Actually, I don't understand your comment.


I'm just alluding to the people that got fired and expelled for involving themselves with "passwords" in the comments above.

If you have JavaScript enabled, the cleartext password is hashed in the browser and the hash is truncated, and a list based on the truncated hash is retrieved to be checked against - the only information leaked is that you searched for one password amongst many. Read Troy's articles about how fishing is protected against - I have written the above from memory.

You can download all the hash files if you wish to run purely locally.

Also the site hosting Troy's list is Cloudflare. Cloudflare act as a https proxy for a large number of sites, so they already have access to a large number of passwords.


Yes - the 4 days is cool... you’d hope if some where had been hacked with your pass you would be notified within that timeframe

Would this suggest that 3DES with a sufficiently long password is still safe for now?

This suggests you don't understand how DES-based crypt() worked, so let's take both angles here:

1. Would it be safe to build a password hash like crypt() based on 3DES today?

Maybe, kind of, it depends, don't do this. "Based on" is key here. You'd have to come up with some way to try to use 3DES in this fashion, just as the developers of Unix crypt() used DES. Basically you're trying to build a cryptographic hash out of a primitive that's not really intended for that purpose, you also need to add more salt than the Unix team did back then, and then you need it to run very slowly, preferably on everybody's hardware not just the generic (likely x86-64) general purpose CPU you're using. Lots of people already built _good_ ways to do password hashing in the 21st century, and if none of those are available somehow you should just use PBKDF2 with SHA256 and a nice big iteration count and that'll be tolerable.

2. Oh, I didn't realise, I just meant is 3DES fine for encryption?

You should not do this. The main thing wrong with DES is the key size is too small, which 3DES fixes (effective key size with full 3DES is 112 bits, which is very short today but probably not the biggest hole in whatever security system you're building). But the next biggest thing wrong with it is that it's a block cipher with a small block size, 64-bits. 64-bits is small enough that bad guys may be able to collide your blocks and set fire to everything. To avoid this: Don't use 64-bit block ciphers, go get a real cipher like AES that uses 128-bit blocks. Done. Why are you still here? Could it be secure if you can defuse the collision risk (e.g. you only encipher very small amounts of data)? Sure, but now you're defining the problem to make the choice of primitive look safe, which is always a terrible idea.


Thanks for the great answer. I am not familiar with DES but the reason I wondered about this is because I saw that some VPN hardware devices still has 3DES as an option and even as the default encryption algorithm. I was really baffled by this because I had assumed that 3DES has completely fallen out of favor. So I guess the company isn't choosing sensible defaults. But at the time, I thought maybe they knew something I didn't (although I still switched the algorithm to AES since there's no reason not to).

Doubt it. It took 4 days for just one top of the line GPU. Any dedicated attacker will have farms to parallelize it even further. It’s not exactly linear, but with just 4 GPUs (~$4000; well within the reach of any dedicated attacker), that’s one day. Not to mention the fact that GPUs have still been roughly following Moore’s Law in terms of performance.

It’s probably safe from the casual attacker who just downloads a password list and runs a one word dictionary attack, but for a dedicated attacker, let alone a nation state, it’s not secure.

TL;DR: Just use AES. Even an ASIC isn’t powerful enough for that. Searching the entire key space would take more energy than the universe has. Compare that to DES that can have its entire key space searched in a few days.[0]

Edit: you said triple DES, not single. My point still stands. DES, even 3DES, is not secure. If I can crack a DES password in 4 days, I can crack a 3DES password in 12. AES with a strong password is virtually uncrackable.

[0]: https://en.wikipedia.org/wiki/EFF_DES_cracker


> If I can crack a DES password in 4 days, I can crack a 3DES password in 12

It's multiplicative, not additive. 3DES is about 2^56 times as difficult to crack as DES. (Not 2^112 times because there is an attack that effectively limits it to twice the effective bits of DES, rather than the three times you might expect at first).


> there is an attack that effectively limits it to twice the effective bits of DES

* Meet-in-the-Middle attack.

https://en.wikipedia.org/wiki/Meet-in-the-middle_attack

This attack is surprisingly simple, if you encrypt the message twice by

    ciphertext = encrypt(encrypt(message, key1), key2)
Then,

    decrypt(ciphertext, key2) == encrypt(message, key1)
An important security property all symmetric ciphers should offer is immunity to chosen-plaintext attack, if the attacker controls "message", it shouldn't make the cipher more easy to crack.

But in this case, the attacker can obtain all the 2^56 possible encryption of message by enumerating key1, put it in a lookup table (assume the table-lookup time is O(1)) , then we can try all possible decryption of ciphertext by enumerating key2. Then compare it with the lookup-table for a match, bingo!

If key is 56-bit, the attacker gets 2^56 outputs for the left side, 2^56 outputs for the right side, total number of operations is 2 x 2^56 == 2^57, not 2^112.

To increase the security claim to 2^112, we need triple encryption, not double encryption, thus 2DES is never used.

The idea that simple double-encryption doesn't work because of such a simple attack shocked a lot of newcomers.


This is mostly irrelevant in the context of password hashing however. We're simply feeding passwords into a blackbox at X/s until we get a match. 3DES runs at approximately X/3 compared to DES. If it takes 4 days to feed a bajillion passwords into DES, it takes 12 days to feed the same number into 3DES.

It might be relevant, because the original asker said "with a sufficiently long password". (Implicitly: with a password longer than 8 characters that the original DES scheme would allow.)

It's more complicated than this, because there are known attacks against 3DES. It's at most 2^28 times more complex, AFAIK, but there are probably better attacks than the few I know.

Are any of these attacks relevant to password cracking?

> It's multiplicative, not additive. 3DES is about 2^56 times as difficult to crack as DES. (Not 2^112 times because there is an attack that effectively limits it to twice the effective bits of DES, rather than the three times you might expect at first).

If you’re using 3 different keys, yes, that makes sense. But if you’re just keystretching one key, wouldn’t it just take 3 times as long because you encrypt, decrypt, encrypt (3 processes)?


3DES is a little more secure than plain DES (but still worse than AES)



Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: