Live data from Hacker News

Lessons learned from cracking 2 million LinkedIn passwords

community.qualys.com

51–60 of 111 posts

Re: Lessons learned from cracking 2 million LinkedIn passwords

#51

I've always wondered why password hashing is not a law (at least in the US). There needs to be an agreed upon minimum level of security for storing credentials. Or, just make it where websites HAVE to state somewhere how they are storing the credentials. It's shocking how many places still use plain text, or encryption and store the key in the database.. It's pathetic that a major company like LinkedIn is simply stor…

>Or, just make it where websites HAVE to state somewhere how they are storing the credentials. It's shocking how many places still use plain text, or encryption and store the key in the database.. I like this idea. Like a Surgeon General's Warning for the web. I wouldn't want the government making specific laws about hashing, but requiring transparency and disclosure about how data is stored would be useful in a vari…

The concern I have with this is that it provides a bit too much information to potential crackers. Security through obscurity is nothing to rely in, but it doesn't hurt to have a little. It's why disabling the reporting of http server version information is a common practice in hardening a server.

OTOH, it may be worth it. It's shocking that LinkedIn could be so negligent, especially after high-profile screwups like gawker.

Re: Lessons learned from cracking 2 million LinkedIn passwords

#52

Earlier quoted context omitted.

They way I see it, and I'm no expert on this topic, a longer password is better than a short, completely random one. The attacker doesn't know how long your password is, so he will start with short passwords. Each additional character adds a lot more possible combinations, so thats where you get your safety from. Now if you include lower/upper case letters, digits and special characters you have increased the search…

But does it actually add entropy when a hacker could use a dictionary and combine those words in various ways? The best practice of using several random words is still 'rule based' - the individual 'units' in the password simply become words instead of characters, and the arbitrary length doesn't really matter. Start with the most common 40,000 words in English, and combine them in all possible orders - that gives 2.…

Add a few fun prefixes and suffixes hither and yon, and you largely eliminate the "token" nature of words as well. Even a couple of well-placed (but ordinarily inappropriate) uns, antis, disens, ousitys and ishnesses increase the problem space dramatically without significantly decreasing (and perhaps even increasing) the memorability.

Re: Lessons learned from cracking 2 million LinkedIn passwords

#53
post #2

no matter how elaborate a password you choose, as long as it is based on words and rules, even if there are many words and many rules, it will probably be cracked So this is what I've been wondering about the current "best practice" to use long passphrases. How are those really any stronger than any other "rule" based password, the "rule" being that they are likely constructed of words and phrases from human language…

I have no idea. I thought they were, but your comment made be do some really naive analysis: For a typical password, each character can be one of around 92 characters, depending on what rules are in place - 26 lowercase letters, 26 uppercase letter, 10 digits, and ~32 special characters on the keyboard (I may have miscounted). Other characters could be used, but these are going to be the most common. This means that…

>you would have to believe that the average person would pick a passphrase like "gastroenteritis jurisprudence algorithm aberration", which is clearly ridiculous.

Oh how I wish my bank and mortgage lender would let me choose easy-to-remember passwords like that.

Re: Lessons learned from cracking 2 million LinkedIn passwords

#54
post #50
post #33

Earlier quoted context omitted.

Given a passphrase dictionary attack, the passphrase would be discovered in less than a minute. Wait, what? 2,048^4 == 2^44 == 17,592,186,044,416 At 2 million hashes/second it would still take 101 [edit: actually, on average, 50] days to find this password, if it was unsalted. Perhaps if you had spent a few years of supercomputer time to generate some massive rainbow tables, you might be able to discover it quickly,…

Diverging from your main point a bit: 2MH/s is unrealistically low. For a couple thousand dollars you can build FPGA HW that can do several billion SHA1 hashes/s. The bitcoin mining world is getting 400-450 SHA256 MH/s from a $130 chip. With similar technology, you can brute force a 2^44 SHA1 space in a lot less than 50 days.

Which is why no-one should be storing passwords in SHA1.

Re: Lessons learned from cracking 2 million LinkedIn passwords

#55
Thus, it is highly recommended to use a strong random password generator that is known to be actually random.

The whole point of a password is that you can remember it. The moment you need software to store and retrieve passwords, you're better off using asymmetric cryptography. That said, I really dislike the idea that it's the only way to achieve security. I would really like to see more discussions and propositions for solving this problem.

Re: Lessons learned from cracking 2 million LinkedIn passwords

#56
post #2

no matter how elaborate a password you choose, as long as it is based on words and rules, even if there are many words and many rules, it will probably be cracked So this is what I've been wondering about the current "best practice" to use long passphrases. How are those really any stronger than any other "rule" based password, the "rule" being that they are likely constructed of words and phrases from human language…

With a passphrase, each word comes from a much bigger set than (alphanumeric + special characters), so it stands to reason that it'd be harder to brute-force. There are speech patterns, though, so it's likely that crackers would be able to reduce the search space somewhat by checking common phrases like "my first car". But change to something like "my first grandma was a 1927 haircut" and you're likely to future-proo…

Or go completely nonsensical. "Vanilla elephant trampoline inverted cork routine" contains no common phrases and is just as easy to remember.

Re: Lessons learned from cracking 2 million LinkedIn passwords

#57
post #55

Thus, it is highly recommended to use a strong random password generator that is known to be actually random. The whole point of a password is that you can remember it. The moment you need software to store and retrieve passwords, you're better off using asymmetric cryptography. That said, I really dislike the idea that it's the only way to achieve security. I would really like to see more discussions and proposition…

It will get to the point that we need biometric scanners or implanted RFID chips with private keys to do authentication, since brute forcing even unrememberable passwords will be trivial eventually.

Re: Lessons learned from cracking 2 million LinkedIn passwords

#58

Earlier quoted context omitted.

You might want to look at a browser extension like PwdHash [1]. It uses a client-side script to generate a cryptographic hash from your common password and the domain name. I've been using it for about four years now and have been generally very happy. It means that if my password ever gets leaked the attackers are not only unlikely to find my password of "ngjO3uBJrvt", but if they get it they do not have any informa…

I don't use that because of (unfounded) concerns that I will someday need to enter my password into some device where it's not available, or the domain will change, or some other scenario where bad things will happen because I do not actually know the password I told the site.

This is why I use LastPass. I can log in (securely?) to their website and pull up the password out of a database in (rare) situations like that.

Re: Lessons learned from cracking 2 million LinkedIn passwords

#59
post #57
post #55

Thus, it is highly recommended to use a strong random password generator that is known to be actually random. The whole point of a password is that you can remember it. The moment you need software to store and retrieve passwords, you're better off using asymmetric cryptography. That said, I really dislike the idea that it's the only way to achieve security. I would really like to see more discussions and proposition…

It will get to the point that we need biometric scanners or implanted RFID chips with private keys to do authentication, since brute forcing even unrememberable passwords will be trivial eventually.

Why? There are plenty of ways to make brute force hard or damn near impossible, it's just a little harder to implement. It has been discussed a lot of times here at HN and other places.

Also, do you really think that storing private keys on RFID would be a wise choice? I would put that in the "stupid as fuck"-category, just above storing your keys on a USB-stick, as they are both easy to copy and duplicate, and with RFID I could do it remotely.

A real solution to all of these problems would be for people to stop reusing passwords. You don't really need the account passwords when you basically have access to all the data there anyway.

Re: Lessons learned from cracking 2 million LinkedIn passwords

#60
post #45

Linkedin allowed 6 character passwords. If a user selected six random uppercase ASCII, lowercase ASCII and numbers, this would be the bit-strength: print math.log(62) / math.log(2) * 6 35.72 bits That's easy to crack. Also, keep in mind that humans don't select chars randomly. So the bit-strength of these passwords was probably closer to 20 bits. I cracked 2.5 million with an old cpu and JtR within a few hours.

This is the advice I give to my family members. The solution is to create a one-time-pad in excel(!) that contains all of your passwords. Store it on an encrypted thumb drive and carry it with your keys. There is the possiblity that your OTP may contain a character set that is not congruent with a web-service's password system, but these circumstances are rare.
Post reply on HN