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 like:
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.
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 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.
I completely agree. "Your password must be at least 10 character long, include 2 upper case, 2 lower case, 2 digits, 2 special characters, must be changed every 60 days and cannot be reused for the next 3 years"
G0Fuc4Y@urse!f
To me this is a sure way that people are gonna pick horrible and stupid passwords.
Even better if it just says "your password does not fit our requirements" :)
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.
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: space , + " % & ' ; = ^ or curly braces.
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.
Depending on your threat model, a strong password that is written on a piece of paper on your desk might beat a weaker password that's memorized. That would at least require physical presence of the attacker and if your desk is reasonably secured, that might be ok for a lot of cases.
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.
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. 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).
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.
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.
86% of my passwords are for low consequence sites.
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.
If you ever reuse that password anywhere else, then you should care A LOT. If you go "i only reuse passwords on low-consequence sites", then I have to ask you 1) why reuse at all? and 2) are you sure? I bet that that's not true, I bet you think that's true but it turns out that your Uber password is the same as your RandomSite password.
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.
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.
I got into the habit of using a separate password for each site I use, except for the throwaway sites.
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
Exactly!! I have a scheme like this but more convoluted, low/medium/high consequence sites, different random 'main chunks' that I can remember, and a quasi-methodical per-site head/mid/tail chunk that is related to each site.
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.
Unfortunately, OSs don't make it easy to use password managers, especially in mobile. A lot of my banking sites also defeat my password manager with bizarre UX like user name masking and multi step login screens.
I use keypassx on Mac, Windows, and Android. It is a minor pain to have to log into it to grab my username and password, but worth it. I sync the encrypted DB with Dropbox.
1. With a password manager, you don't have to think anymore if a site is high-consequence or low-consequence.
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.
To be honest, the first one that comes to mind is HN. There is zero consequence if someone was to get a hold of my credentials here — I don't care about the score and I can still recover the bookmarks.
What if the person that takes over the account posts messages that arouse the interest of authorities? Your IP addresses and other info are associated with the account.
I think this is a pseudo-problem in pretty much any country except for, perhaps, totalitarian regimes or similar. If any large body would take interest in the account seriously enough to get the associated IP, they would also automatically get the new account holder's IP and the clear correlation.
> 2. What kinds of websites that require a sign-in are actually low-consequence?
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.
Low-consquence? Typically one-off purchases from random internet vendors; if no saved credit card details, just a way to view past orders. Risk is leakage of more PII, like address.
Forum logins risk reputational damage, but otherwise are reasonably limited. Some people use specialist forums to ask one-off questions, for example.
I had a login at a game website called Shakes & Fidget years ago. The site itself is low-consequence. I wouldn't care if someone hacked my login. Another example is when I'm just trying some service and don't expect to use it ever again.
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
Maybe it's not such a big deal if someone hacks your account on one 'inconsequential' site, but what if they do it across 10, 20 'inconsequential' sites?
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.
>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.
'Security' is some kind of religion in tech circles. I don't know if it is just that risk analysis isn't part of your standard tech education, or if they think it makes them look cool to talk about always using 200 character hardware-RNG generated passphrases when ordering pizza online, or what exactly, but they're everywhere.
Yeah some people I know go OTT and use password managers for everything. To the point that they don't trust any cloud based ones so if they want to log in to something and they haven't got an up-to-date copy of their password manager db on them, they can't.
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.
How many seconds have you, GP, and a couple of other commenters in this subthread devoted to thinking that maybe people who use password managers for everything find it not merely secure but also convenient?
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.
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"
If you're responsible for running a website, how are you going to be resilient against attackers who come to your site with legitimate usernames and passwords of your members?
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.
But for this it is probably good that the services do fingerprint us - so that we understand how well it can work. Otherwise we'd assume that cleaning cookies is enough and wouldn't know how well that tracking works, not only when services that we knowingly use are doing it, but also when some actual black hats do it.
Also if someone attempts to change an email address linked with an account, an email could be sent asking for confirmation. 2FA is also becoming easier to implement for low level developers with Authy and Google Authenticator offering simple to follow boilerplates and documentation. Validation algorithm that forces a dictionary attack on password before successful registration could also be prudent.
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.
Letting users choose passwords is the default behavior of websites, but it's incredibly dumb.
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.
Can't possibly work. Everyone is going to have their own notebook for passwords, protected by rubber band. Yay.
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.
These arguments aren't convincing me. I still like devit's idea.
> 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.
At bare minimum websites should use 2FA - a simple TOTP on any smartphone will do wonders.
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
Out of curiosity, I just looked at the list of sites in my password manager, and at least 3/4 of them are sites that I shouldn't even need an account to use! Mostly online shopping sites the wouldn't let me checkout without an account and forums that wouldn't let me do some function without an account.
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.
I have 118 entries (which seems scary) and a quick scan shows me about 95% are not rubbish (I guess there is a selection process) and something like 2/3rds I have some kind of financial relationship (HMRC/VAT, paypal, phone provider) as well as a (small) number of stores (I think Jeff Bezos needs to be thanked for that)
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
The point i am making is that why are you using those crappy websites.
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.
The depressing thing is that every new company I join has terrible password hygiene: shared accounts (even on services that don't force it), passwords reused on multiple services, terrible passwords, passwords emailed around, passwords in word docs that are emailed around ...
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.
My biggest bugbear is with the really important sites like Apple and Google who force you to type out your passwords several times a day when using their services. I really want to pick a long complex password, but not if I have to keep typing it into login screens or pop-up windows where password managers don't work. Microsoft is doing a lot of good things in this area with passwordless logins and asking for PIN codes instead of passwords. I wish Google and Apple would follow suit.
TBH I want solutions that work for all logins, not just a select few.
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.
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?
Have you tried zxcvbn [1]? It’s a pretty good heuristic, with common names and character replacement built in, alongside the ability to provide a custom dictionary with heavy weighting (eg your user’s names, email, address).
Aside from the thought that a portion of these bad passwords may be for throwaway accounts, I think what we really need is a "Beyond Passwords" movement similar to the push for Let's Encrypt.
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.
> 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?
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!
My preference is for long passwords that comprise a natural language sentence. They are easy to remember and hard to brute force once they are greater than 40 characters. You don't need any of these draconian password rules if the password is long enough.
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.
The takeaway is that if your site handles highly sensitive data like financial or medical records and you allow users to login with just an email and a password, you are doing it wrong.
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.
I should have said 'extra information', not 'extra field'. A username with random characters like C85Y922 is clearly more secure than an email username.
Of the 6 major banks you use how many have email address as the username?
Some require a separate username crafted by the bank, but they are low entropy. Something like last name plus 2 digits. One is a clearly sequential integer of limited range.
Usernames are not secrets and add no security by being kept secret. Just lengthen the damn password instead!
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.
I'll grab the data and make some easy to use bloom filters so nobody has to rely on a third party API to send passwords to. I can make different filters for hashes grouped by count so that I can get a rough estimate of how exposed it is.
Stop giving your users passwords to Troy Hunt! Eg. hash and salt them! But use a really slow hash. Lets say the hashing speed is one hash per second, then it would take trillion years to brute force the password "hello".
You have that backwards. You don't bruteforce a single password. You compute the hashes of all the dictionary words and then compare the hashes. So your 'trillion years' is probably more along the lines of a few weeks, for all the words in the dictionary at once.
Yes! (I've edited my comment and added "and salt") and with a tiny bit of obscurity like a hashing algorithm that can't easily be calculated by a GPU or ASIC, then the hackers probably wont bother. Because scrypt is used by Litecoin, Dogecoin, et.al there are now ASIC's capable of billions of scrypt hashes per second.
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
I'm in the process of revamping a backend's password mechanism. After reading something like this I just want to adopt hardware keys or Google Authenticator INSTEAD of passwords.
Because my password manager is faster than checking mail. Because spam. Because people change mails and may forget to let you know. Because bots scan emails and they are mostly in clear text.
> Because bots scan emails and they are mostly in clear text.
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.
The truth is the password is just another failed security concept- because those that work, cant be remembered by the users.
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.
We do have alternatives — global open cross-platform standards such as hard tokens based on the FIDO U2F and WebAuthN standards even. We're just not at the point where both users and services are willing to use these technologies.
Password managers are a band-aid on a fundamentally flawed technology. They are what we have now, so (if your tech savvy) that's what you're using. But it's an absolute shame that this is where we're at.
I'm optimistic about the FIDO standard as a password replacement. Exciting things happening in that space recently!
Password managers are best practice, but they are a reaction to the failures of passwords, rather than an attempt to replace passwords with a better proposal.
* 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.
I do this but I'd love to have someone tell me why this is a terrible idea (apart from the obvious one of using a 3rd party sha256 calculator)
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
1. This relies on a mistaken expectation that all sites you use being able to accept SHA256 output - presumably in Base64 or similar- as an acceptable password. You will likely have to compromise this.
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.
At some point a site you use will be compromised, so you have a problem as that site will require a new password.
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.
I'm not sure what you are saying ... should I memorize dozens of passwords like WCLfx(edI%uHgjWM6RuEeC6Qh for the services I use or should I strap on getting those dozens of services to use a perfect SSO service that doesn't leak privacy and is perfectly secure and doesn't exist yet?
(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?
If it is well integrated with your browser it's quite ok. Maybe not as convenient as using the same simple password everywhere but certainly a lot better than having to remember a lot of different passwords ;)
I personally prefer _not_ integrating my password manager with my browser, even though the option is available. Instead my password manager performs manually-activated autotyping which, while less convenient, does at least 'feel' like it's more secure.
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].
Just wait. Someday you will see dumps of pwnt password that look like:
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.