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

"Pwned Passwords" V2 With Half a Billion Passwords

troyhunt.com

Post reply on HN
Print view View original

241–250 of 369 posts

Re: "Pwned Passwords" V2 With Half a Billion Passwords

#241

Post by C14L »

lopmotr wrote: post #197
markdown wrote: post #86

Earlier quoted context omitted.

A warning about Cloudflare: You cannot access their support in any way without logging in. Trying to contact them via their contact/sales page won't work. They won't respond. This means that if you lose your phone (2FA) and can't log in, you're royally screwed and will have to go to your registrar to recover access to your domains/DNS.

You should never use only 2FA for something you don't want to be locked out of. You need a 3rd authentication method to replace the 2nd when you lose it, such as backup codes, that as well as a 4th one to recover a lost password.

Pretty sure backup codes are just a part of 2FA.

Re: "Pwned Passwords" V2 With Half a Billion Passwords

#242

Post by professorTuring »

odammit wrote: post #230

Split brain your password storage. Another table, another database or another storage system in general. If an attacker SQL injections your database don’t go spilling every hashed or unhashed password you’ve got. I tend to store passwords in a separate keyvalue store from where my authentication identifier is (email, “username”). If someone gets into my network they need to get into my servers with the email addresse…

Rule n1: don't roll your own security. Rule n2: goto 1

You are overcomplicating your authentication system by oversimplifying security problems and the result is that you have solved nothing.

Security always seems very easy to solve and usually non-security engineers tends towards solutions like yours that doesn't provide extra security, they just add a few extra steps for a hacker to obtain you database and as a result you need to maintain extra databases, there are more error points... Do you remember that thing about "each extra system exponentiates complexity"?

Re: "Pwned Passwords" V2 With Half a Billion Passwords

#243

Post by odammit »

grzm wrote: post #240
odammit wrote: post #239

Earlier quoted context omitted.

You need both. https://www.trustedsec.com/2016/06/introduction-gpu-password...

All security decisions boil down to your threat model, doesn't it? At some point there are decreasing marginal returns with increasing security. What threat models are you satisfying with the strategies your proposing? Do you think these apply to everyone? Or even everyone who stores hashed passwords? I personally don't think so, but I'm interested in hearing about things I haven't come across yet.

A day of engineering effort to make exposing passwords much more difficult. Yes. If you’re a company that stores someone’s password. You know they probably use it elsewhere so it’s your responsibility to help keep it safe.

Also I left the link off above ^

Re: "Pwned Passwords" V2 With Half a Billion Passwords

#244

Post by sah2ed »

jaequery wrote: post #233
odammit wrote: post #230

Split brain your password storage. Another table, another database or another storage system in general. If an attacker SQL injections your database don’t go spilling every hashed or unhashed password you’ve got. I tend to store passwords in a separate keyvalue store from where my authentication identifier is (email, “username”). If someone gets into my network they need to get into my servers with the email addresse…

go a step further and you will get into key management devices like the HSMs and/or the Amazon KMS. KMS cost almost next to nothing and it is pretty neat since its a web service, especially coming from the world of $40k+ Thales/Safenet HSM devices which are a pain to deal with (backups, rehash, redundancy).

Mind sharing how you currently use Amazon KMS in practice?

Re: "Pwned Passwords" V2 With Half a Billion Passwords

#245

Post by odammit »

professorTuring wrote: post #242
odammit wrote: post #230

Split brain your password storage. Another table, another database or another storage system in general. If an attacker SQL injections your database don’t go spilling every hashed or unhashed password you’ve got. I tend to store passwords in a separate keyvalue store from where my authentication identifier is (email, “username”). If someone gets into my network they need to get into my servers with the email addresse…

Rule n1: don't roll your own security. Rule n2: goto 1 You are overcomplicating your authentication system by oversimplifying security problems and the result is that you have solved nothing. Security always seems very easy to solve and usually non-security engineers tends towards solutions like yours that doesn't provide extra security, they just add a few extra steps for a hacker to obtain you database and as a res…

You don’t have to “roll your own security.”

You can easily put any open source security system behind a secondary system. Hell - it would already be a secondary system.

Not putting your passwords right next to the identifiers is a simple way to lower the impact of an email or password leak.

Also, that quote is bullshit.

Re: "Pwned Passwords" V2 With Half a Billion Passwords

#248

Post by rspeer »

prewett wrote: post #229
rspeer wrote: post #203

Earlier quoted context omitted.

This list is small for the purposes of password-cracking. Enumerating 500 million things is something a computer can do very quickly. Consider this: if you store the hash of one of these passwords in your login database, you have stored something that can quickly be turned back into the plaintext password, just by enumerating the list. Passwords that have been leaked can't become good passwords again.

> Passwords that have been leaked can't become good passwords again. This doesn't make any sense. We already know all possible passwords: the set of all the permutations of the set of legal password characters of a given length. Your argument applies equally well to these. You can't just use these passwords and check the hash, since the database (hopefully) at least salted their hash to prevent rainbow attacks like t…

Okay, I may be overstating just how quick it is -- you might have to spend a few days of CPU time to go through the whole list, based on estimates I'm seeing. (Parallelize it however you want.)

But don't act like I don't know there are a finite number of passwords. The number of possible passwords grows exponentially with length, and the number of leaked passwords grows linearly with leaks.

It's about the number of possible passwords you have to check. There's a huge difference in magnitude between having to hash "all 10-character passwords" and "all 10-character passwords that are definitely someone's actual password".

Post reply on HN