Live data from Hacker News

86% of CrashCrate subscribers used passwords already leaked in other breaches

troyhunt.com

131–140 of 145 posts

Re: 86% of CrashCrate subscribers used passwords already leaked in other breaches

#131
Does anyone know of good libraries to gauge password strength or find easy password. I'm conflicted between using all leaked password vs. simply excluding super popular and well known pattern. Not sure exactly what measure to take to stop easy password. The password crackers now recognizing so many patterns some of the big passwords can be very trivial and it can be hard to recognize those.

I have found some libraries that seems to have the right idea but would love a recommendation of what are the best/easiest one specially if can find one in Java and is not overly convoluted.

Also love recommendation of open source self hosted 2FA solution. Looking at the core process of TOTP and prompt based 2FA (public key crytography) there's seem to be no reason either cannot be implemented as a library. Am I incorrect in that assumption?

Re: 86% of CrashCrate subscribers used passwords already leaked in other breaches

#132

Earlier quoted context omitted.

I don't think you understand how he gets ahold of these passwords. They're from dumps of leaked databases.

I think parent's comment is telling people to store passwords in such a way that they won't be very useful if they are leaked.

Exactly! A password "hash" function is an algorithm that will turn a password string into a seemingly random string. Where it's impossible to figure out what the password is - based on the output string from the hash function. And the hashed string is saved in the database instead of the password. When the user logins the database runs the hash function. eg "SELECT * FROM user WHERE pw = hash($pw_input)" For example my md5 hashed password is a8b767bb9cf0938dc7f40603f33987e5

Now hackers are smart and will generate a "rainbow table" of all possible words and their corresponding hash (try google the md5 hash above). But then we can "salt" the password by adding a random string that is unique to each user, and the rainbow table becomes useless. "SELECT * FROM user WHERE pw = hash(concat($pw_input, salt))"

But hackers don't give up so easily. Using GPU's and dedicated hardware they can generate billions of hashes per second, so they will just "brute force" hash all possible words (dictionary and more) together with the salt. To counter this we use a slow hash function, a function that takes up to 100ms to run, and now the hacker can only brute force ten passwords per second! Meaning it will take years to find even a simple password.

If we all start doing this: slow hash function + salt - then Troy Hunt wont have any more passwords! Sorry Troy!

And also if users use long passwords with some special characters like !"#¤%&/()= for increased entropy, then it will be even harder for the hackers to brute force them. Using only numbers a five letter pasword has 10^5 combinations. Using only lowever case letters there's 28^5 combinations. Using upper and lower case plus special characters and numbers there's like 80^5=3 billion combinations. If we now increase the password length from five to ten characters there's now 80^10=ten Quintillion combinations. Cracking it with 10 hashes/per second would take 30 billion years. But if it was a fast hash lile any of the popular md5 or sha where you can have a few billion of hashes per second it would take "only" 30 years. Where as a password with only five letters would take less then a second to crack.

Now you think 30 years is a lot, but then there's Moore's law, where number of transistors will double every second year, leading to increased compute power. So two years from now those 30 years would only be 15 years. And 20 years from now those 30 years will be only one year! Think of this when you use what was considered best practice in the 80's

Re: 86% of CrashCrate subscribers used passwords already leaked in other breaches

#133

Earlier quoted context omitted.

before I got into a password manager, I resorted to song lyrics, capitalizing the first character, including a number and a symbol at the start. '#1I'm picking up good vibrations', for instance.

A tad off topic, which password manager would you recommend?

I started with LastPass, but switched to OnePassword when LP was acquired by LogMeIn. OnePassword (the standalone client) was great, but it didn't work with linux at the time.

I ended up trying keepassxc for a time, but ultimately ended up with bitwarden, which has served me extremely well.

BitWarden isn't as polished as OnePassword, but its not far off. Since its purely browser-based, it works with every OS.

Re: 86% of CrashCrate subscribers used passwords already leaked in other breaches

#134

When I feel like a security goon's arbitrary and capricious password policy is irrational and counterproductive, I make my passwords worse in the hopes that I have to someday read it to someone, or perhaps it gets spilt outin the open, and then everyone will see how forcing me to pick a password that adheres to certain characteristics solved nothing. Just wait. Someday you will see dumps of pwnt password that look li…

Just recently Estonian Information System Authority published a new report (including new guidelines for passwords) basically telling: "Drop password requirements, allow long passwords and restrict the use of short and top-n passwords". Why I'm mentioning this is because now I have an actual official document I can send to Estonian companies in addition to my own words (that weren't previously believed, ugh) why thei…

Why is the solution always regulation with you people

Re: 86% of CrashCrate subscribers used passwords already leaked in other breaches

#135

Earlier quoted context omitted.

The only appropriate password requirement is length. A policy that requires 12 or 14 characters alone will have much better security than all these character sets, time limits, and other nonsense while only requiring 6 or 8 characters. And these sites that limit password length to ridiculous short lengths are infuriating. Who could have possibly ever thought that was a good idea???

Not necessarily. "aaaaaaaaaaaa", "password1234", and "pennsylvania" are all 12 characters, but they're all insecure. These might seem like stupid passwords that nobody would use, but if you enforce a minimum password length as your only requirement, then I guarantee some user is going to use something like this. I agree that length is generally much more important than anything else - but it's not the only factor. Lo…

You're right that dictionary words are weak, regardless of whether they are long or short. Same applies to anything that can be arrived at by a simple heuristic such as dictionary word + 1, capitalized dictionary word, dictionary word with "@" substituted for "a", etc..

However, outside of the above caveats, it's a common misconception that more complex is more secure. Which of these is harder to crack?

catzzzzzzzzzzzzz

db0mcgn20y64zzn7

Since an attacker is unlikely to arrive at either of these through a dictionary or heuristic, they will take roughly equally as much time to brute force.

When you force users to comply with arcane password policies, a high percentage of them are going to build their passwords in very predictable ways that are easy to code into a heuristic, like replacing "o" with "0" or something. These kinds of changes add no security value and are just extra work/bother for the users. With the length requirement, it's unlikely they're going to think of a dictionary word off the top of their head that is long enough (how long did you have to think about it to get pennsylvania?), and thus, on average, you're more likely to get more passwords that are a couple of words, or a phrase, or something that is a lot harder to dictionary attack. Once you break away from the dictionary, complexity doesn't matter, only length.

Re: 86% of CrashCrate subscribers used passwords already leaked in other breaches

#136

Earlier quoted context omitted.

Just recently Estonian Information System Authority published a new report (including new guidelines for passwords) basically telling: "Drop password requirements, allow long passwords and restrict the use of short and top-n passwords". Why I'm mentioning this is because now I have an actual official document I can send to Estonian companies in addition to my own words (that weren't previously believed, ugh) why thei…

Why is the solution always regulation with you people

Because profit-driven businesses never bother to do anything that doesn't bring profit, even less when it requires effort.

Re: 86% of CrashCrate subscribers used passwords already leaked in other breaches

#137

Earlier quoted context omitted.

Such a rebel. Remember that at the end of the road it’s your identity your password protects.

> your 90 day password expiration rotation schemes Those scenarios are almost always a bad employer policy, in which case it's their data the password is protecting.

It's often because of regulation. PCI standards, for example, require this.

Re: 86% of CrashCrate subscribers used passwords already leaked in other breaches

#138

Earlier quoted context omitted.

Unless they've changed it in the last couple months, TRowe Price still limits passwords to 10 characters. And this is after a recent "We've upgraded our security!" push where I had to reset everything. I've seriously considered closing my accounts over it. Edit: Yep, still as bad Password must be 6-10 characters and contain at least 2 numbers and 2 letters. Password may not contain the following special characters: s…

my bank's password has to be exactly 8 characters and is case insensitive it's pretty insane considering it's like the most important password I have

I've got one better: my online banking requires 7 digits exactly, numbers only. This is so you can use the same "password" in their phone banking thingy.

Re: 86% of CrashCrate subscribers used passwords already leaked in other breaches

#139

When I feel like a security goon's arbitrary and capricious password policy is irrational and counterproductive, I make my passwords worse in the hopes that I have to someday read it to someone, or perhaps it gets spilt outin the open, and then everyone will see how forcing me to pick a password that adheres to certain characteristics solved nothing. Just wait. Someday you will see dumps of pwnt password that look li…

I like this entropy based password strength checker:

https://github.com/dropbox/zxcvbn

Here you can see that it realizes that all your passwords are weak: https://lowe.github.io/tryzxcvbn/ (it says: cracked in minutes, or seconds, in an offline attack)

And it does this without requiring uppercase or symbols or numbers. It even understands that passwords like "qwerty" are trivially cracked – it looks at how far the keyboard keys are from each other. Among lots of other things.

Re: 86% of CrashCrate subscribers used passwords already leaked in other breaches

#140

Earlier quoted context omitted.

I'm not talking about password managers (in this case) You should worry about strong passwords, but the point is moot if the rest of the system has other major flaws. See: people who have their security answer as a long hex string, and customer service doesn't check the digits.

It's hard to tell what security answers are used for when you're writing it in. If it's for use with customer support, it should probably be something like "CSR IMPORTANT: DO NOT ACCEPT VAGUE ANSWERS 309c91b10edb2"

Good idea! Yeah it's usually for CS and id verification.

(It's also a good idea to, if you use correct answers, to not leave them on Fb or other places)

Post reply on HN