86% of CrashCrate subscribers used passwords already leaked in other breaches
troyhunt.com
troyhunt.com
Just wait. Someday you will see dumps of pwnt password that look like:
Password-1234
Password_1234
Password!1234
Password&1234
Password?1234
Password$1234
And that is rated as a "VERY STRONG" password.Have fun with your character diversity, and your 90 day password expiration rotation schemes. Go ahead and try to force me into a corner. I'm still picking terrible passwords and I'm picking especially terrible ones because someone out there is trying to pull my strings.
Pull my strings. Make me more predictable within your little security policy world. See how that plays out.
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 their requirements are inane. I think this kind of behaviour shows that we actually need some kind of monitoring or regulation here to build more secure software for everyone.
Also as you mentioned bad-"strong" passwords, I "love" how something like "Qwerty!1234" satisfies most requirements but "8f434346648f6b96df89dda901c5176b10a6d83961dd3c1ac88b59b2dc327aa4" is not okay because it doesn't contain an uppercase letter or a symbol.
You and 50 others.
G0Fuc4Y@urse!f
To me this is a sure way that people are gonna pick horrible and stupid passwords.
I was signing up for a bank account and had to make a password for my online account in the branch. Turns out my 16-character randomly generated password made the system unhappy. Tried 6 more times with newly generated passwords (character-only, alphanumeric only, alphanumeric and "#" or "$" only) and it just said the password was not acceptable. So in the end I used my probably ~15 bits of entropy super easy to crack password from when I was 10, with a few randomly generated characters on the end (because more than a few would make the system complain again).
The pervasiveness of poor UI and security design baffles me. You would've thought that one of the largest banks in the world would have a little more competency but nope.
You forgot "and may not be longer than 16 characters".
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: space , + " % & ' ; = ^ or curly braces.
it's pretty insane considering it's like the most important password I have
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.
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???
I agree that length is generally much more important than anything else - but it's not the only factor. Long passwords can be insecure too. Unfortunately it's not easy to validate what exactly what makes an insecure password, and as a result we get stupid requirements that prevent some very good passwords (e.g. diceware-generated passwords).
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.
Those scenarios are almost always a bad employer policy, in which case it's their data the password is protecting.
I have a bank site that I have to log in to every month, but only once a month. So every 3rd time I use the site, I have to choose a new password. Very annoying.
How much should I care if someone hacks my handle and posts ads on a chat site? Or reads registration-required articles under my registration? Or etc etc.
Just use a password manager. It's easier and it's safer, and you never have to think "is this a low consequence site?" ever again, because you'll have high quality passwords everywhere. It's really the only way to be sure you have unique and strong passwords everywhere.
>why reuse at all?
Because it's easy. There's many sites I create an account for once or twice and I never use again, mainly e-commerce. I don't care if someone logs in, at best they get an address and maybe a few card details. That's all practically public information.
>are you sure? I bet that that's not true
Yup, 100%. And even if a few get missed, anything super important has 2fa, on top of using semi-unique passwords that adhere to a format so I can guess them in <5 attempts if I don't have my password manager on hand. And I check them semi-frequently in haveibeenpwned.
>Just use a password manager.
I agree this is good advice in general but even with decently designed password managers, like dashlane and lastpass, people often don't like to use them for various reasons. My parents get confused by new software. I tell them "use a very strong password for google, amazon, ebay etc, and if any other site asks you for a password use a weaker one". If they used a password manager I guarantee they'd get overwhelmed when it comes to using it on different devices and give up, reverting to worse security than before.
Also in the end, people are astronomically more likely to fall for phishing emails than be the victim of a security breach from password re-use. Seriously the whole "use a password manager with a RNG upper/lower/symbol/number combination" trend is overhyped and honestly a distraction from more pressing security issues. Google estimated phishing victims are 400x more likely to have their accounts compromised than anything else[1]. And as someone who is currently dealing 90% with phishing attacks over any kind of password related incidents I'm very inclined to agree. If you're a public figure and therefore an actual individual target for motivated attackers then yes, use RNG passwords and a password manager with 2fa and only ever store the db on a memory stick which you keep on a chain around your neck, otherwise it's not really necessary.
[1] https://www.bleepingcomputer.com/news/security/google-ranks-...
I have a method I use regardless if 2fa is an option or not.
I have a fairly secure password that I have memorized. Then for each site I pick something about it that I can remember to add on to the password.
For example if my current ebay password is: Pa$$w0rd the new one would be: Pa$$w0rdEb or EbPa$$w0rd Amazon would be: Pa$$w0rdam
That has helped a few people I know keep separate passwords for each site without having to go through a password manager. YMMV of course.
The way I look at it is if the sites DB gets dumped, at least the scripts will fail using the password on other sites, even if it's not the most secure password.
You're point about the phishing e-mails is spot on though. No amount of secure passwords will stop that
Never found any of even the main chunks in the PW lists, but I'm sometimes forced into stupid PWs by stupid rules as in above comments.
2. What kinds of websites that require a sign-in are actually low-consequence? I can't think of any from the top of my head, but that's probably because I'm pretty reluctant to sign up to new sites.
It's usually not a function of the site, but a function of the site and the user. pg would probably care more about his HN account than user051783254. That said, some sites where I expect the majority of users (mostly the non-paying ones, but perhaps even the paying ones depending on the payment mechanism) would probably not care about their accounts being hijacked might include: HN, StackOverflow, CodeProject, AllTrails, Disqus, Last.fm, SlickDeals, etc.
Forum logins risk reputational damage, but otherwise are reasonably limited. Some people use specialist forums to ask one-off questions, for example.
What would worry me is if people hack the login for a low-consequence site and then figure out that those login credentials for this user are the same everywhere: at their bank, Amazon, etc. Personally, I use different passwords at every single website, but at low-consequence websites I sometimes use less secure ones. I don't see how this is a problem (for me).
I understand why low-consequence sites do not implement schemes to force users to use stronger passwords, though. Howls of outrage, lost users, and attempts to get around it, as charDiversity says: https://news.ycombinator.com/item?id=16975773
Or probably: sites that don't involve money.
You may not give much away on one site, but combine all that data across multiple sites, and maybe I can start building a profile on you, identify you, impersonate you, steal your identity, etc.
Why would someone go through that much effort on one person when they can end out a million phishing emails with two minutes of work, get a few thousand replies, get a few hundred people buying their scam and walk away with a six figure payout? The chance of you getting your identity stolen because of password reuse is about as low as getting killed in a terrorist attack: it's not really worth thinking about or putting too much effort into preventing when you're more likely to get hit by a car.
My system is two or three "disposable" passwords I use on low reputation sites or sites where I don't care about breaches. I don't care about people knowing it either, if someone asks and I trust them I'll more often than not tell them what it is. Services where compromise would actually affect me get stronger passwords: my Google and Amazon passwords semi-random generated, but sticks to a format so I change parts of it and never forget it, and I check to make sure it's not in breaches every now and again. I use variations of it for my bank, medical stuff, etc where a breach could actually have implications for me.
The usual cargo-cult thinking usually ends up with someone leaving their 1024 bit secret key under the doormat, or worrying too much about nation states hacking your routers instead of worrying about Bob clicking a suspicious link.
I don't know about you but I don't like having to remember passwords. But people here can feel free to impress everyone with their memorized password they use on pizzahut.com, right up until they find out that they reused it somewhere important they totally forgot about because they don't have a convenient database of all the websites they have an account on.
Seriously, this counter-culture of being proud to have shitty passwords is the same mindset that makes antivax and climate science deniers a thing. You want to reuse shitty passwords, nobody is stopping you (I've certainly done it), but don't be proud of it and don't shit on people who care more than you.
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 also a good idea to, if you use correct answers, to not leave them on Fb or other places)
One way is to email the user when they log in from a new device or computer.
They then have to enter a 6 digit one time password from the email.
Someone who grabs the users email and password from a breach would also need access to their email.
I use auth0, and have it configured for passwordless use.
If you have a Google Account or Microsoft Account then you can simply use the OIDC / OAuth flow and have those third parties that you trust identify you and handle the authentication... we only ask for an email as it's necessary for our service. Because it's only auth0 talking to the identity provider, Google and Microsoft don't actually get to see which site you're signing into.
If you don't have those, then you can just use an email code. We email you a single-use expiring (15 minutes) code, you enter it and gain access.
In this scenario email becomes your identity.
I use private browsing for everything... this is a bit inconvenient as password managers cannot handle this email verification flow. But for me that's good... I want this level of security for myself, I want the service not to be storing passwords whilst also not permitting identity providers to know what I'm signing into.
I use KeePass and Kee for firefox, and it works the same in private browsing as in "normal" browsing.
Just like SQL injection and query prepare statements, issues are very much known but it's the want and need to act on them. GDPR should start to help this, but management tier individuals who push development time scales are also needing to be 'sold' the importance of this.
Just generate a random password on the server side and tell the user to store it in their password manager or in a plain text file.
Do not let users enter their own password under any circumstance.
All password issues solved instantly (yeah, if the client is compromised the password is too, but the attacker can install a keylogger and accomplish the same task anyway).
Plus it's much more user friendly, since the user just needs to follow instructions and is not required to somehow "invent" a password.
Also, I use a password manager on my machines (for websites I use privately: amazon, taxes, etc.), a different one at work (for corporate tools). I also use my own passwords + 2FA(if available) for things I use at both places (like my own gmail, HackerNews, etc.).
Forcing users to remember/write down something is just a bad idea. Chances are your "reset password" feature will be DDoS-ed into oblivion by your legitimate users.
Much better alternatives:
* the Google push notification: [0];
* a YubiKey or similar U2F token [1];
* a way to turn my smartphone into an automated keyboard that holds my secrets.
[0] https://www.howtogeek.com/260369/how-to-set-up-google%E2%80%...
> Can't possibly work. Everyone is going to have their own notebook for passwords, protected by rubber band. Yay.
I don't consider this a bad thing per se. A notebook of secure passwords is a lot better than dictionary passwords. (Dictionary in the sense of a leaked password dictionary.)
> Chances are your "reset password" feature will be DDoS-ed into oblivion by your legitimate users.
I had a co-worker who, on most sites, set passwords by mashing the keyboard and then always logged in using the reset password functionality. I also don't see the problem with this.
But, the issue is that 86% of all websites offer so little value that 86% of people would just not bother using the site if they had to do the 2FA dance each time.
That is the fundamental problem here - not people reusing passwords, or password policies that break when encountering my password manager.
It's not surprising people use rubbish passwords to access rubbish websites
If all online shops were required to let me buy something without creating an account, my "password footprint" would be about 1/2 of what it is.
Overall I am surprised - I would be prepared to use 2FA for quite a lot of those (many I do).
And if those sites mostly moved over to using OAuth with Google or a more privacy minded provider, yeah I would be fairly happy.
In fact why does Apple not do OAuth2? They have the privacy-is-our-thing going for them (as opposed to Google / Facebook whose business model is selling my data).
After that I guess its the UK government Gov.Verify for commercial users
I am thinking of a mars bar right now - it's utterly fucking pointless for me - i'm fat enough as it is and it has no nutritional value. so anything that increases the height of the bar to me buying one is fine by my slow thinking rational self. Sugar taxes, backroom, top shelf mars bar vendors are my bag baby.
Just say no.
If IT people can't get this right, it's impossible for the average person to EVER get this right. We need a better solution.
We need the OS makers (e.g. Apple, Microsoft, Google) to create a standard protocol for login windows that apps like 1Password, LastPass, Dashlane, etc can use. We kind of have it on iOS but not all app makers got the memo. Although I fear that they'll end up pushing for their own managers, taking business away from the password managers that are saving us.
And even that I believe is simply because they don't want me forgetting the password.
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?
I use KeePass 2.x on my laptop and it's been great for having complex passwords, but the few seconds it consumes to load it up every time just to log into a site is annoying. Worth the trade off, of course, but can't we do better?
Browsers, operating systems, and sites need to cooperate on making password managers as low-friction as possible. Once that's done, it's time to explore other options for users, like dongles (Yubikey?) or those "no password login" mechanisms like what Mozilla was running with Persona. Sad they discontinued that.
It's flexible and secure, and most of the major players are onboard with the standard. I use and love KeePassXC (as everyone should at this point), but passwords have too many fundamental problems to be the future.
Yubikeys are nice, but don't fit everyone or everywhere. The FIDO standard is flexible enough so that it can use one or more of many different authentication factors, biometrics on your smart phone, secrets stored in the browser, PINs, Yubikeys, and others.
https://fidoalliance.org/about/what-is-fido/
Particularly exciting to me is W3C's recent standardization of the protocol. It's starting to take off!
Keepass only takes 1-2 seconds to open the database. Once that's done, no more delay...
Ctrl-Alt-K on Windows brings the window to focus, click on password entry, Ctrl-V and poof, auto-typed in!
'#1I'm picking up good vibrations', for instance.
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.
if (isPwInBlackList(propossedPw)) throw new Exception("Proppossed pw is in black list");
logger.info("Password {} is OK.", propposedPw); //<-- faulty code here
[0] https://www.bleepingcomputer.com/news/security/github-accide... dated 2018-05-01
Almost no bank website allows login with just email/password - there's always some extra field required such as a User ID with random characters, an account number, a PIN number or a code from a second device. The reason is simple: if the bank accepted just email/password there would be a lot more fraud and the bank would lose money.
Of the 6 major banks you use how many have email address as the username?
Usernames are not secrets and add no security by being kept secret. Just lengthen the damn password instead!
Ofcourse this is not optimal, but I think this is more convenient than let say sending a login link via email.
I've given up remembering passwords for important accounts and just use the 'forgot me password' button to auth through email.
If your site or service doesn't have more than 100 million users, please don't require a password for my email. Let me log in with another trusted account (Google, Twitter, etc). I miss the days of oauth2 and the flexibility of authenticating small services.
Google and a few other massive corporations already control way to much of my life, adding control over authentication of my online accounts is simply unacceptable.
It'd be way more acceptable if it was an open standard and I could choose which trusted ID provider I wanted to use, but I've not seen it work like that so far.
https://itunes.apple.com/mx/app/key/id1348022074?l=en&mt=12
Hope it is useful to someone.
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
If the password reset email goes through the same route then this doesn't matter.
It's essentially a 'password reset' with every login. And because they are short lived you'd expect that if they had been used already that there would be no re-use possible, which would mean the attacker would have to be super fast and the victim would immediately know they were under attack.
So ones security researches terrible, is a neurologists reasonable. The actually embarrassing part is that after years of research- we still do not have a alternative.
Remind me what's wrong with "correct horse battery staple" again?
I'm optimistic about the FIDO standard as a password replacement. Exciting things happening in that space recently!
Or even better: Some kind of hardware token and a good standard that goes with it?
* Password Managers are good but inadequate as a solution because, at present, only a motivated set of any given number of users are likely to make use of them.
Do we want a solution that works well for all or nearly all users? Or will we simply settle for a solution that protects only ourselves?
At present, password managers are often third-party luxuries even though they are indispensable for basically every person. In truth, they are essential enough that standardized API hooks for password managers really ought to be baked into every consumer OS, and if we are serious about protecting users in a world where 86% of passwords are terrible, users should have to explicitly opt out of whether to use a password manager or not.
The only choices most users should be making are
* whether to use a default or nominated password manager,
* what physical tokens / 2FA approaches they want to use
* and whether they want their credentials to be stored in the cloud (convenient) or only ever stored locally (more secure, credential transfer fully under control of users).
Sites / Applications / etc requesting credentials should really provoke a standardized credential request UI on the OS, not have bespoke credential dialogues in a thousand different designs and approaches bleeding all over the internet.
The choice to have a distinct credential per site should not be a choice offered to most humans, because most humans will always make the wrong choice.
1. Have a very short prefix and a suffix I can expect to remember 2. Password for every website gets generated like this <prefix> + website name + <suffix> 3. Generate SHA256 hash of #2 4. Use #3 as password for the site. 5. Save password to password manager
Pros - 1. losing a password on one site doesn't compromise the pattern on others because cracking sha256 is still not possible (afaik) 2. relatively easy rules to create new password 3. If I HAVE to login on a computer without my password manager (e.g., public workstation), I can regenerate my password on the fly.
Cons - 1. I use an external sha-256 calculator 2. Some sites enforce password length and arbitrary case/symbols rules. Have to manipulate generated password by hand
2. You have no credential expiry built into this approach. Even should you decide to not use credential expiry, if one site demands it, your strategy doesn't work.
3. You are still at risk of having your passwords leak because: Anyone who compromises a public machine on which you generated your password manually (eg leaving any traces in logs, bash history etc) who eyeballs your SHA256 input prefix_ashleymadison.com_suffix , now has very clear reasons to expect they can generate passwords based on prefix_facebook.com_suffix and pre_barclaysbank.com_suffix because your credentials between sites are now not independent of each other, and worse, directly suggest each other.
Ignoring keyloggers and bash history issues etc any simple 'over the shoulder' attacker, likewise, get a pretty good guess at all of your passwords all at once by observing you generate a password for one site just once.
In short, if you attempt to use an approach like this, you no longer just have to protect your password, you have to absolutely protect the knowledge of the algorithm by which you generate your password for different sites. This being compromised just once potentially compromises all your passwords, substantially widening the ways in which you can be harmed.
Good point. I'll have to add something to prefix of prefix/suffix for sites which remember previous passwords (or hashes).
> leaving any traces in logs
This I will have to resolve by localizing my sha256 generation process.
> over the shoulder
Also a good point.
Thank you for thinking this through for me. Appreciate it.
So your login routine is now:
* Generate your password via hash(prefix + sitename + suffix), and use it on every site, except that compromised one. Because it invalidated your old password and won't let you reuse it.
In short you have a versioning problem. And you have to remember it. The problem compounds for each site you use which insists upon a change for whatever reason.
(Also your own "con" - different sites have different restrictions/caveats for password formats.)
Use a password-manager, it really is the best way to have a unique and secure password for each site.
I do use my Mac's Keychain Access. My issue started when I had to use a work computer for logging into a newspaper account and I couldn't remember what it was because it was saved on my personal laptop. That's when I came up with this scheme.
> versioning problem
Someone else pointed this out as well. Thanks for thinking this thru.
(And you do need to memorize your password manager password - and your main email account password as well)
Also a lot of leaked passwords were strong, they just got compromised because someone didn't know about 70's password security basics.
Should we just never use any leaked password ever again? (Note I'm not saying: with the same login - or any of the "top 100") Should we really trust all of our passwords to one service that might get compromised or just go away?
Should we bother creating a strong unique password for that new cool SF startup that doesn't know how to use bcrypt?
I trust my OS to isolate applications from eachother more than I trust my browser to isolate extensions from the page they run on. LastPass in particular have had their browser extension exploited[0].
[0]: https://blog.lastpass.com/2017/03/security-update-for-the-la...