Lessons learned from cracking 2 million LinkedIn passwords • Hacker News Board

Re: Lessons learned from cracking 2 million LinkedIn passwords

#81

Post by robomartin » Mon, Jun 11, 2012, 5:26 AM UTC

abraham wrote: post #38

robomartin wrote: post #35

With all this talk about security I am still wondering why everyone isn't up in arms about the fact that Chrome makes all of your stored passwords plainly visible at the click of a button or two. This has been the case for years and many complaints have been recorded, but Google, for some strange reasons, seems to refuse to even attempt to put forth any effort to secure their browser.

There are going to be much better discussions about this in Chromium discussion archives but I'll cover one of the main reasons why Chrome and Firefox (by default) do not have a master password. If someone has physical or remote access to your computer it is an endgame scenario and it does not matter if you have a master password enabled or not. The most basic attack is just to install a keylogger and steal the maste…

I understand this very well. Here's one scenario: Busy office. Hundreds of computers. Open environment (no doors, just a bunch of desks/tables). Everyone using Chrome.

The current version of Chrome would allow someone to, within a few clicks, grab a pile of passwords.

Here's another scenario: Your mother takes her laptop to be repaired/updated. She uses Chrome. The entire repair shop has easy, unencumbered access to all of her passwords and logins.

Similar scenario: Computer goes to IT guy where you work for repairs/updates. He now has any and all of your passwords and logins with no effort.

My point is that for all this talk about security it seems really dumb for a prominent player (any prominent player) to not take extra steps to ensure that our valuable data is secure within reason. With LinkedIn the problem is, at the very least, the lack of anything beyond SHA-1 to protect passwords. Bad idea. In the browser case, it seems to me that, unless the intent is to provide a browser used only by those like us who understand and are very aware of security issues, it might just be a good idea to put in a few things that will make it harder for curious eyes or the 16 year old at the repair shop to grab all of your login data.

I don't propose nor do I expect perfection or absolute security, but what Chrome does today is, in my opinion, at the very least irresponsible. The uninformed user has NO IDEA WHATSOEVER that a huge security hole exists in their browser. Maybe we need to stop thinking in our terms and focus on mom, dad, uncle or grandma. When you first install Chrome you should, at the very least, see a screen telling you about security and the options you might have. I think that a master passwords would most-definitely serve a purpose in the case of "innocent" peeking. Yes, with pro's all bets are off. It's only a matter of time until someone tracks identity theft to the lack of browser security and they sue the fuck out of the browser publisher.

Re: Lessons learned from cracking 2 million LinkedIn passwords

#82

Post by chmike » Mon, Jun 11, 2012, 5:35 AM UTC

rikf wrote: post #64

head -c x /dev/random | uuencode - where x is the length of the password you want.

How do you remember it ? What do you do if you need to login from another computer ? This doesn't work on my windows computer. If we store this random password in a local pasword storage, how much different is that from using asymetric keys (rsa,...) ?

Re: Lessons learned from cracking 2 million LinkedIn passwords

#83

Post by DanBC » Mon, Jun 11, 2012, 5:45 AM UTC

AgentConundrum wrote: post #11

ams6110 wrote: 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…

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

There are many more short words than long words, thus a person would be very unlucky to pull out that passphrase.

But what if you reduce the space? Instead of using a dictionary with about 175,000 words, why not use the Diceware list, which has only 7776 words? None of them are over 6 letters long (I think.) A few words are numbers; or have special characters.

Because many websites won't allow you to use a diceware passphrase you'd use a good password safe with a long diceware passphrase. You'd then let the safe generate random passwords for you.

Re: Lessons learned from cracking 2 million LinkedIn passwords

#84

Post by Locke1689 » Mon, Jun 11, 2012, 6:48 AM UTC

ralph wrote: post #73

Locke1689 wrote: post #69

Earlier quoted context omitted.

To generate random alphanumeric strings drop the following into your zshrc: function mkpw () { if (( $# == 0 )) then head /dev/urandom | uuencode -m - | sed -n 2p | cut -c1-${1:-12} else head /dev/urandom | uuencode -m - | sed -n 2p | cut -c1-${1:-$1} fi } By default it generates an alphanumeric string of length 12. Given an integer argument n it generates an alphanumeric string of length n.

Why the test of both $# and $1? tr -dc '!-~' Change to A-Za-z0-9, etc., to suit.

Mostly because I'm terrible at shell scripting. Thanks.

Re: Lessons learned from cracking 2 million LinkedIn passwords

#85

Post by re_todd » Mon, Jun 11, 2012, 7:14 AM UTC

jackalope wrote: post #23

dkokelley wrote: post #18

Earlier quoted context omitted.

Well, calculating the "true" strength is difficult to do, because even though sophisticated tools are available to aid the process, the attackers are still human, and can input their own guesses that may or may not be more accurate. If the attacker knows (or can closely guess) the password rules used to generate your password, he or she has a better chance of getting a hit. Let's look at a password like "My first car…

Beautifully written. Also worth noting is that sites exist that only use lower(trunc(password, 8), so your first 8 characters should be sufficiently random. For the grandparent, that leaves "my first", which is especially weak in a dictionary attack.

I've heard of sites truncating to only use the first 8-12 characters as well. So if you are going to use lots of words, put them after a highly complex first 8 characters.

Re: Lessons learned from cracking 2 million LinkedIn passwords

#86

Post by nodata » Mon, Jun 11, 2012, 7:18 AM UTC

Someone wrote: post #32

dkokelley wrote: post #18

Earlier quoted context omitted.

Well, calculating the "true" strength is difficult to do, because even though sophisticated tools are available to aid the process, the attackers are still human, and can input their own guesses that may or may not be more accurate. If the attacker knows (or can closely guess) the password rules used to generate your password, he or she has a better chance of getting a hit. Let's look at a password like "My first car…

One improvement: for most people, the risk is not that someone tries to crack your password, it is that someone uses rainbow tables to crack many passwords, one of which may be yours. Rainbow tables have a degree of freedom: the function that maps hashes back to passwords. You should try and pick a password that that function will never generate. To get that, do something unique. Good options, I think, are including…

I thought GPUs killed rainbow tables? (the storage space alone makes them impractical compared to cracking realtime)

Re: Lessons learned from cracking 2 million LinkedIn passwords

#87

Post by shenberg » Mon, Jun 11, 2012, 8:03 AM UTC

dkokelley wrote: post #70

Someone wrote: post #32

Earlier quoted context omitted.

One improvement: for most people, the risk is not that someone tries to crack your password, it is that someone uses rainbow tables to crack many passwords, one of which may be yours. Rainbow tables have a degree of freedom: the function that maps hashes back to passwords. You should try and pick a password that that function will never generate. To get that, do something unique. Good options, I think, are including…

Can you explain more about this rainbow table function? From what I understand, rainbow tables are simply precomputed hashes of common passwords. What you're saying is that we should use passwords that aren't in a rainbow table, which by definition implies that the passwords are not common.

Rainbow tables are a clever way to implement a time/space trade-off for finding the inverse of a hash value in general by doing a lot of precalculation (see wikipedia, the core nice idea there is explained under "hash chains" in the Rainbow Table page).

Besides, rainbow tables are supposed to be pointless because everyone's supposed to be using salt with their passwords...

Re: Lessons learned from cracking 2 million LinkedIn passwords

#88

Post by peterkelly » Mon, Jun 11, 2012, 8:50 AM UTC

So here's an idea:

Pretty much every site with a login facility has an "I forgot my password" option where you put in your username or email address, and it sends you a link to reset your password. This is effectively a second form of authentication - the ability to receive email at that address implies the ability to log in to that account.

So what about an authentication mechanism that works as follows:

1. You type in your username

2. The site emails you a one-time authentication token (as part of a link)

3. You click on that link and then you're logged into the site

Of course, there are a few obvious problems with this: it's a bit cumbersome to have to do for every login, email is unencrypted, and message reception uses a pull-based mechanism.

So I could envisage a standard, incorporated into browsers, as follows:

1. When you first launch your browser, you log into an authentication server S, supplying your password (either manually, or automatically via a saved password)

2. When you want to log in to a site, you type in your username, and the site sends an authentication token to the server S

3. S sends a push notification to your browser with the authentication token

4. Your browser passes this token to the site, and you're logged in

This way, your (hashed + salted) password need only be stored on server S (in the first example, this corresponds to your email server). This means that apart from S, none of the sites you use need to store any password information at all.

I'm sure this basic idea has been implemented previously in other contexts. Why are we not using for all our web logins?

Re: Lessons learned from cracking 2 million LinkedIn passwords

#89

Post by peterkelly » Mon, Jun 11, 2012, 8:53 AM UTC

peterkelly wrote: post #88

So here's an idea: Pretty much every site with a login facility has an "I forgot my password" option where you put in your username or email address, and it sends you a link to reset your password. This is effectively a second form of authentication - the ability to receive email at that address implies the ability to log in to that account. So what about an authentication mechanism that works as follows: 1. You type…

A clarification of the second point 2: The site needs to know the address of server S, and your account name on that server (i.e. just like username@domain.com with email). So the system doesn't have to be centralised.

Re: Lessons learned from cracking 2 million LinkedIn passwords

#90

Post by LinXitoW » Mon, Jun 11, 2012, 8:57 AM UTC

saulrh wrote: post #71

0003 wrote: post #60

Earlier quoted context omitted.

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.

Just use keepass. If you're already carrying around a password file, you can carry around portable binaries of the program that reads your passwords. www.keepass.info

sadly, Keepass is not very Mac/Linux friendly, because it's built on .NET, so it's only an option for pure Windows users.