Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How we cracked millions of Ashley Madison passwords

cynosureprime.blogspot.com

Post reply on HN
Print view View original

11–20 of 173 posts

Re: How we cracked millions of Ashley Madison passwords

#11

Post by kijin »

nilved wrote: post #7

What's the risk of using plaintext passwords if we assume every user is employing long, random, unique passwords? This has always seemed like a non-issue to me because I've been using a password manager for a half-decade. e: Downvoting questions is mean. FWIW I always use bcrypt.

Long, random password stored in plaintext: as soon as the user database is compromised, the attacker can log into your account and do whatever they want. This may result in additional exposure of information that wasn't part of the original compromise. The attacker can also impersonate you and cause other kinds of damage.

Long, random password hashed with bcrypt/scrypt/etc: if the user database is compromised, the attacker gets the user database and nothing else.

Re: How we cracked millions of Ashley Madison passwords

#13

Post by hattenn »

valarauca1 wrote: post #9
nilved wrote: post #7

What's the risk of using plaintext passwords if we assume every user is employing long, random, unique passwords? This has always seemed like a non-issue to me because I've been using a password manager for a half-decade. e: Downvoting questions is mean. FWIW I always use bcrypt.

Could you recommend a good password manager?

Try LastPass.

Re: How we cracked millions of Ashley Madison passwords

#15

Post by hellofunk »

asadhaider wrote: post #6
chinathrow wrote: post #4

I abandon any sites which give me direct logins via URLs sent over plain text emails. I know, password reset keys are as bad as login keys, but usually they expire after a certain time frame. F*ck login keys.

Completely agree, Match.com does the same thing. Not so long ago a user signed up to their site using my email address (never figured out why). They were able to create an account and subscribe to the site without ever verifying the email, so for a week or so I was getting notifications sent to me without any way to unsubscribe from the email. Clicking any of the links in the email signed me in as the user and gave m…

This is frightening. Who is running the security teams at these large companies?

Re: How we cracked millions of Ashley Madison passwords

#16

Post by JosephRedfern »

sillysaurus3 wrote: post #10
nilved wrote: post #7

What's the risk of using plaintext passwords if we assume every user is employing long, random, unique passwords? This has always seemed like a non-issue to me because I've been using a password manager for a half-decade. e: Downvoting questions is mean. FWIW I always use bcrypt.

Any attacker who snags the server's database will have access to all accounts. When the passwords are hashed, they won't.

I don't quite follow. If they have access to the server's database, then unless the rest of the DB was encrypted using a key derived from the users password, will they not have access to all the accounts anyway?

(edit: I should perhaps make it clear that I'm not suggesting that passwords shouldn't be hashed, merely that if you have access to the database containing the password hash, then in many cases you'd already have access to the data that knowing the password behind the hash would provide).

Re: How we cracked millions of Ashley Madison passwords

#17

Post by nilved »

kijin wrote: post #11
nilved wrote: post #7

What's the risk of using plaintext passwords if we assume every user is employing long, random, unique passwords? This has always seemed like a non-issue to me because I've been using a password manager for a half-decade. e: Downvoting questions is mean. FWIW I always use bcrypt.

Long, random password stored in plaintext: as soon as the user database is compromised, the attacker can log into your account and do whatever they want. This may result in additional exposure of information that wasn't part of the original compromise. The attacker can also impersonate you and cause other kinds of damage. Long, random password hashed with bcrypt/scrypt/etc: if the user database is compromised, the at…

Chances are if they have database access, they can do that already. Many/most exploits at the application layer are made to gain access to the database.

Re: How we cracked millions of Ashley Madison passwords

#18

Post by nerdy »

JosephRedfern wrote: post #16
sillysaurus3 wrote: post #10

Earlier quoted context omitted.

Any attacker who snags the server's database will have access to all accounts. When the passwords are hashed, they won't.

I don't quite follow. If they have access to the server's database, then unless the rest of the DB was encrypted using a key derived from the users password, will they not have access to all the accounts anyway? (edit: I should perhaps make it clear that I'm not suggesting that passwords shouldn't be hashed, merely that if you have access to the database containing the password hash, then in many cases you'd already…

They may not necessarily have compromised the entire system.

Consider for example, SQL injection. Alternatively, some kind of DB dump mistakenly exposed in the webroot. Neither should happen but they're real-world examples. Sometimes misconfiguration leaves you in a weird state.

Re: How we cracked millions of Ashley Madison passwords

#19

Post by sillysaurus3 »

JosephRedfern wrote: post #16
sillysaurus3 wrote: post #10

Earlier quoted context omitted.

Any attacker who snags the server's database will have access to all accounts. When the passwords are hashed, they won't.

I don't quite follow. If they have access to the server's database, then unless the rest of the DB was encrypted using a key derived from the users password, will they not have access to all the accounts anyway? (edit: I should perhaps make it clear that I'm not suggesting that passwords shouldn't be hashed, merely that if you have access to the database containing the password hash, then in many cases you'd already…

The login process looks like: User navigates to login screen and sends plaintext password to server. Server hashes the plaintext password and compares it to the hash on disk. If the hashes are equal, the server grants access.

Since a user can only submit a plaintext password, not a hash, then they won't be able to log in unless they know the correct plaintext password. Even if they have a copy of the server's db, they won't be able to use any info within it to log in as anyone else unless they use brute force to reverse a hash.

EDIT: It's true that the attacker might have a copy of all the user's data. But unless they know someone's plaintext password, they can't log in as them. The attacker might have a copy of your tweets, but they won't be able to log in as you and send a new one.

There are only a few ways an attacker can snag a database. Most of the attacks let an attacker download it, but not modify it. For example, directory traversal lets you download ../../../../etc/passwd along with ../../path/to/database_backup.

Even if an attacker has shell access, it's unlikely they'd be able to use the service or change a user's password by manipulating the database directly. They might not be able to modify database for a number of reasons: the database might require credentials the attacker didn't get, or the attacker might only have access to a server containing database dumps rather than the database itself, or the attacker might be logging in as a user which has read-only access to the database file.

Re: How we cracked millions of Ashley Madison passwords

#20

Post by nilved »

valarauca1 wrote: post #9
nilved wrote: post #7

What's the risk of using plaintext passwords if we assume every user is employing long, random, unique passwords? This has always seemed like a non-issue to me because I've been using a password manager for a half-decade. e: Downvoting questions is mean. FWIW I always use bcrypt.

Could you recommend a good password manager?

Self-hosted: http://www.passwordstore.org http://keepass.com http://keepassx.org

Paid: http://lastpass.com http://1password.com

Post reply on HN