20 ms·

Passwords Evolved: Authentication Guidance for the Modern Era

440 points by Spydar007 9y ago

kutkloon7 9y ago
The problem with a password manager is that you don't have easy access to one when you're on a different machine. A better way is to use a scheme that hashes your username, service name, and master password to generate a password. A problem is that this doesn't always comply with the arbitrary demands on your password. This is why these arbitrary demands need to die: they make the only way to securely and conveniently access accounts from different devices impossible.
- wutwutwutwut 9y ago
  Your suggestion is bad for a ton of reasons. For example, how do you change your password for a specific site after it had been compromised or due to normal password rotation? Another downside is that changing master password means you need to change passwords for all sites or have multiple master passwords. Another is that an attacker can use the knowledge of your password on site A to bruteforce your master password offline. And so on...
  - l0b0 9y ago
    Why on earth is this being downvoted? If you've used a hashing generator for any length of time you'll know how multiple master passwords inevitably creep in. Also, when your generator no longer works because the login FQDN changes (which happens alarmingly often) you'll have all the fun of resetting your password. For no good reason. Re. portability, KeePass and its siblings are compatible with every major platform.
    - Globz 9y ago
      I have access to my password manager at all time, thanks to https://minikeepass.github.io/ https://minikeepass.github.io/ on iOS! You can even sync your database to all of your devices by storing it inside an encrypted volume for extra security.
      - kutkloon7 9y ago
        Does this also work when you use someone else's phone or computer?
  - Lagged2Death 9y ago
    ...an attacker can use the knowledge of your password on site A to bruteforce your master password offline. This might be a concern if you're the victim of a state-level targeted attack. That's not a threat most of us have to deal with. Hackers aren't likely to spend a lot of effort cracking John Doe's password list; they want to steal a few million password hashes and sift out a few thousand easy or re-used ones. Your other points about the weaknesses of the scheme stand. Still, if we could get more users to use not-terrible, not-duplicated passwords, even with a flawed scheme like this, overall internet security would improve immeasurably.
    - dublinben 9y ago
      You don't need to be the victim of a state-level targeted attack. You just need to be a public figure online[0] and attract the attention of a bored hacker. [0] https://www.theverge.com/2012/8/6/3224597/mat-honan-hacked-apple-icloud-google-twitter https://www.theverge.com/2012/8/6/3224597/mat-honan-hacked-a...
      - Lagged2Death 9y ago
        I'm not super familiar with the Honan story but I recall (and quick skimming seems to confirm) that it was more about lax security policies at Apple et al, the interconnectedness of social media accounts, and social engineering than it was about reversing a computed hash or human "hashing" scheme. Did those attackers guess or compute even one password at all?
        dublinben 9y ago
        Not in this specific instance, but they could have. And that level of scrutiny would have enabled a complete digital takeover like Honan suffered if his accounts were poorly protected by a system of passwords proposed above.
    - IncRnd 9y ago
      This is false. There are many types of targeted attacks on passwords that don't come close to including state-level actors. Divorces. Corporate Espionage. Any one of the people on Judge Judy who posted information online about their co-workers.
  - kutkloon7 9y ago
    You can add something (e.g. a number) to the end to make a different password. The idea is that you have a _very_ secure master password (so bruteforcing it is not practical - to make this even more true you could hash a huge number of times instead of just once) and never change it. There is still some truth in your arguments. I'm curious what you consider a good alternative?
- notzorbo3 9y ago
  > hashes your username, service name, and master password Security through obscurity. You're essentially just using the same password on every site now.
  - dspillett 9y ago
    Ish. If you use a sufficiently good hash function with a salt to stop rainbow table based attacks and key strengthening for good measure, then an attacker who has one compromised password of yours isn't going to be able to reverse the hash to find what your source password is so that they can generate new per-site passwords using it. That is assuming they even try: how would you know that an arbitrary string of characters was generated that way rather than just being randomly picked by a password manager? Of course all your accounts are compromised if someone knows your master password, but that is little different to an attacker getting your pass-word/-phrase for an online password manager that doesn't use some form of 2FA.
    - IncRnd 9y ago
      No. This is not a cryptographic attack on the hash but on the text that is being hashed.
      - dspillett 9y ago
        But how would the text being hashed be attacked without either attacking the hash by brute force or knowing the master password (which is likely a human factors hack, to which online password managers are similarly susceptible?
        IncRnd 9y ago
        Using hash functions in an attack is not the same as performing a cryptographic attack against the hash function. These are two different classes of attacks, both being real-world attacks. The attack being discussed is against a suggested formula to generate passwords. From the top of the thread, "a scheme that hashes your username, service name, and master password to generate a password." Discovering the password by determining the inputs to the hash function is all that is needed. This is the case even if a different type of function is used instead of a hash. Apologies, if I gave a different impression.
- kijin 9y ago
  How often do you need to type passwords into a machine that you either cannot or are unwilling to sync with a decent password manager? How do you trust this machine not to record and exfiltrate everything you ever typed into it? IMO it's a Good Thing (tm) that I have to jump through hoops to access my passwords on unfamiliar machines. How does one even calculate H(username|service name|master password) on an unfamiliar machine that might not have a decent scripting language installed on it? If you asked me to do it on my father's laptop, for example, I'm gonna have to download Python first.
  - Sniperfish 9y ago
    Re. the number of machines, it's something I've encountered as an obstacle from a fair proportion of people I've spoken about password managers to. I think its more a perceived issue than a real one. Just spitballing which systems I would realistically want access to passwords on, at a minimum, includes: personal desktop, personal laptop, tablet(s), cellphone(s), family (parent, sibling, in-laws, etc) computers, office desktop, office laptop. In my case (many cases?), the latter two prevent software installation, so I would need to manually type from a manager synced on my cell. Which really is no different to what is required for 2FA - just a longer character string. Overall, a some setup and synch related inconveniences but not to a damaging degree, which is why I think this is more a matter of perception - once you think through where you're typing passwords it appears less of an obstacle.
    - darylfritz 9y ago
      > the [office computers] prevent software installation, so I would need to manually type from a manager synced on my cell. I don't know about other Password Managers, but LastPass lets you access your vault using any web browser. So long as your network doesn't block the LP site, you can access your password manager from anywhere.
      - NMDaniel 9y ago
        On a similar note, Keepass can be used without admin rights with the portable version, so you can keep the portable executable along with the encrypted db file in some secure and accessible email account/web service that your network doesn't block.
- deleted 9y ago
  [deleted]
- blowski 9y ago
  Most of my passwords never need to be typed onto strange machines, so I can use 1Password with long random complex strings. If it is a password I need to type, I use diceware "Correct Battery Horse Staple" style passwords. If I don't remember the password, I always have my phone, where I can retrieve the password from 1Password. There is no relationship between my different passwords. As long as my password vault is secure, so are all my passwords. With your system, if I learn your master password and hashing mechanism, I basically have all your passwords.
  - notzorbo3 9y ago
    FYI, diceware has been shown to be insecure with three words. Four is better, but also crackable by an attacker with a few thousand dollars to throw at it. Five and up is safe for the next few years.
  - kutkloon7 9y ago
    True! So you have to choose a good master password and use an expensive hash. On the other hand, if you take any other approach, you place either confidence in the security of a service (1password), or you store passwords somewhere. In both cases, you have a problem when you can not retrieve the passwords anymore. If 1password is hacked or simply offline, or your phone gets stolen, you basically lost access to all services.
- IncRnd 9y ago
  > A better way is to use a scheme that hashes your username, service name, and master password to generate a password. A problem is that this doesn't always comply with the arbitrary demands on your password. This is a very bad mechanism to create passwords that will create severe security vulnerabilities. You are adding complexity and false-security without benefit. Passwords are a secrecy mechanism, not a formula mechanism. In your method, all one needs is the formula, then all passwords will be disclosed. The suggestion might then be to interject a secret with enough entropy into the text being hashed. But, that is no different from a secret password itself!
- davchana 9y ago
  I have to mine all the time, on my phone, KeepassToAndroid app. Its synced one way (PC to Phone) via dropbox, so that I can edit database only on PC.
- 0xffff2 9y ago
  While I don't particularly like this approach, there's at least one product that does just this: https://lesspass.com/#/ https://lesspass.com/#/
shadowashe 9y ago
passwords are clearly still a gigantic problem in infosec for the users https://blog.binaryedge.io/2017/07/24/antipublic-password-analysis/ https://blog.binaryedge.io/2017/07/24/antipublic-password-an...
- dspillett 9y ago
  On a quick scan that looks like interesting analysis. Though one point that I find most run-downs like that miss is the number of accounts that are throw-aways, where the user simply doesn't care and will never use it again. At that point using "123456" or "password" isn't an issue, anyone who hacks the account gets nothing more than they would get if they just created a throw-away account themselves.
  - codinghorror 9y ago
    The hacker can grief / spam everyone else in the system from this "normal" account. Depends how much public interaction / content posting there is, though.
    - DownGoat 9y ago
      True, but this is not really a problem for the user, but a problem for the system. It is reasonable to assume that the user that creates these type of accounts does not really care about the security of the system either.
- deleted 9y ago
  [deleted]
gourou 9y ago
https://www.xkcd.com/936/ https://www.xkcd.com/936/
- dspillett 9y ago
  Somewhat redundant as that is actually referenced by the article itself, both as a general discussion point regarding passphrases/passwords and specifically because that specific string is actually found a number of times in the reference data sets.
gourou 9y ago
https://www.baekdal.com/insights/password-security-usability https://www.baekdal.com/insights/password-security-usability
tomp 9y ago
Ah, passwords. Look, webmasters, the simple truth is - I don't care. I have a default password that is very simple to memorise (and hence guess/hack), that I use for most logins, because frankly, I just don't care. Unless you're vitally important to my life (email, Facebook, backup, services that I use so often that they keep my personal/credit card data), your login/password is just an annoyance for me, as is your password security policy. I commend reddit and webshops that allow "checkout as guest", that recognise this.
- Analemma_ 9y ago
  You really should be using a password manager then. You still only have to memorize one password, but you’re not severely compromising your security anymore.
  - TeMPOraL 9y ago
    Parent's point is that they don't care. It's not their security being compromised, but the site's. There are plenty of sites out there with unnecessary registration requirements. I don't mind setting a weak, throwaway password on those.
    - BlackFly 9y ago
      Don't forget to use a throwaway email account! Lot's of good email providers give temporary aliases for this reason.
      - msla 9y ago
        I like Spam Gourmet: https://www.spamgourmet.com/index.pl https://www.spamgourmet.com/index.pl
    - naasking 9y ago
      > Parent's point is that they don't care. It's not their security being compromised, but the site's. He'll care plenty if his hacked account posts a threat against the president and he gets a visit from the secret service.
koolba 9y ago
This is a nice article. Only thing missing is calling out "secret questions" as asinine. I loathe when sites require you to set them up as it requires manually generating a series of N-length random strings (ex: eZDWzazuMw0ZzD4nKhxXXVN3) and saving the pair (question plus random text) as metadata associated with the account. Not exactly pulling teeth but it's pretty annoying to manually do that for 3-5 entries. Even worse offenders are the sites that don't even let you enter a value in a text box but instead require you to pick from a drop down with a handful, say 10-15, of entries (cough United Airlines cough). And the very worst offenders are the ones that, after successfully authenticating with your password, ask you for the answers to the secret questions every single time you log in (cough again United Airlines cough).
- aczerepinski 9y ago
  It's nearly impossible to remember what you answered for those questions anyway. For first car did I write "Ford", "ford", "Focus", "Ford Focus", etc? I don't have a specific favorite movie or song. Lord knows what I entered into one of those boxes a year or two ago. Whatever it was, I bet it wasn't as secure as my password.
  - thinkfurther 9y ago
    > For first car did I write "Ford", "ford", "Focus", "Ford Focus", etc? No biggie, the person telling you at length about the quirks of their first car until you mention what your first car was will happily try them all.
    - rockostrich 9y ago
      One of the questions my bank asks is what middle school I went to and I used my elementary school by mistake. I just listed every school I went to to the guy on the phone when trying to unlock my account. It's a good thing they also ask for SSN/amount previously in the account/who your last check was made out to and that sort of thing.
      - deleted 9y ago
MarkMc 9y ago
This is a great article, but it doesn't acknowledge that there is sometimes a tradeoff between security and profit. For example, imagine a typical user who tries to choose a password: User: I want my password to be "monkey" System: Sorry, that password is in the dictionary User: OK, I want my password to be "monkey1" System: Sorry, that password is on a list of exposed passwords User: Grrr! OK, I want my password to be "monkeymonkey" System: Sorry, that password is on a list of exposed passwords User: Grrr! OK, I want my password to be "monkeyfuckyou!!!" System: Sorry, that password is on a list of exposed passwords User: Screw this, I'll just sign up with one of your competitors.
- shandor 9y ago
  The real problem relating to "profit" in these cases is that companies are not penalized at all for leaking their users' secrets, not the fact that security has "tradeoffs". Software industry is in the same boat regarding this as car manufacturers were decades ago, i.e. it was "more profitable" to make cars that killed their passengers in every other car crash, since people were just making the very rational choice of buying the cheaper rather than safer car.
- weinzierl 9y ago
  It's a usability nightmare. I played a bit with password crackers recently and to me it is still often completely counterintuitive which passwords are easy to crack and which are not. Now good luck explaining that to your users without frustrating them. Take for example '_=$%=_$ _ !'. Why is that a bad password? Because it's in one of the common wordlists (yes, it has two spaces and no, I didn't make that up). That's why I think there should be more focus on the point that users should never produce passwords themselves, but leave that job to a good random generator. This is also something I missed from Troy's otherwise excellent article. What is the point of using a password manager if you only use it to store your weak passwords? I also believe the argument about passwords being memorable is a red herring. It is possible to remember a low number of sufficiently long truly random passwords. It takes effort and it is risky, but it is not impossible. Producing a good password without the help of a random generator on the other hand is simply impossible.
SeoxyS 9y ago
One thing that bothers me about this article, and the way everyone does passwords is this assumption that the output of a cryptographic had function is alphanumeric. It's not, is binary. Store the actual data in your database, not the base16 representation! This applies to anything, not just passport hashes—don't transmit around data as base64 unless you're actually using a medium that requires it (e.g. email)
- GordonS 9y ago
  What's the issue with storing password hashes encoded as base64?
  - arethuza 9y ago
    It's going to be a third bigger than storing the bytes directly - which doesn't seem that big a deal. Storing images or video base64 encoded in a database columns would be silly but for hash values I'd be inclined to go for something that is slightly easier to code against.
  - zimbatm 9y ago
    It's unnecessary CPU work and also takes more storage space in the database. In practice I doubt that it makes much difference in terms of performance as hashing is way more expensive than base64-encoding. The rant is probably more against the misunderstanding of developers.
  - yourapostasy 9y ago
    Good question, I'd like to know SeoxyS's reason, too. Aside from the space consideration already mentioned, if I had to surmise, I'd guess it would be faster to process because we're skipping the encode/decode steps unless we are explicitly "importing" or "exporting" the hash, and less chance of making mistakes to encode/decode through Base64 before doing anything with the hash. It is marginally more of a hassle to debug in a live production environment, though. When you are troubleshooting, grabbing the binary representation and running it through a Base64 decoder is annoying. Doing this from inside a mass file search to look for all instances of the same hash can be a bother. I suspect we're storing as Base64 everywhere because so many hashes are held in XML files, and the standard strongly encourages storing binary within XML as Base64. Once they are doing it in an XML file somewhere, I gather lots of teams make that the canonical representation everywhere, even in a database when it isn't strictly necessary.
jimktrains2 9y ago
The problem with passwords on the web is that they require sending and trusting private credentials to someone else. As devs we need to working on making better systems (e.g. TLS client certs and SRP (e.g. TLS-SRP or PAKE)) more usable. It's not a magic bullet and not something a switch can be flipped on, but the status quo is terrible.
- IshKebab 9y ago
  Or OAuth.
  - wedowhatwedo 9y ago
    Not the current OAuth. It is different for each provider. The standard isn't strict enough. I have to write something special each implementation I want to use. The standard needs to be modified so every implementation works exactly the same way - then I'd say OAuth would be a good potential solution.
  - jimktrains2 9y ago
    The provider of an oauth endpoint normally still requires you to send your private credentials. It also ties a lot of identities together making it not Angkor solution for many people.
- dublinben 9y ago
  Like U2F?
  - jimktrains2 9y ago
    U2F is definitely nice, but it's impracticle to expect everyone to have a hardware key. There are software only wins that can be much better than the current status quo. Sure, you can gave software U2F keys, but that's not commor or expected from what I understand.
    - ptoomey3 9y ago
zwily 9y ago
Does anyone provide a regularly updated bloom filter of exposed passwords you could use for meeting the last point? Seems like something Troy could do...
- welder 9y ago
  If it's for your website, start by adding a password strength meter using zxcvbn[1]. For example: https://github.com/MorrisJobke/strengthify https://github.com/MorrisJobke/strengthify [1]: https://github.com/dropbox/zxcvbn https://github.com/dropbox/zxcvbn
- jdormit 9y ago
  Do you think the chances of false positives would make a bloom filter a bad choice for this?
  - Deimorz 9y ago
    It's not ideal, but shouldn't be a big issue, since a false positive just means that you (very rarely) tell a user that a password is unacceptable when it should have been fine. That's a bit annoying for the user, but the result is that they just end up picking a different secure password. False negatives would be worse. Really though, a list of common passwords to block is such a small amount of data that it's probably best to just use an exact list. I can't see it being more than a megabyte or so.
    - zwily 9y ago
      A "list of common passwords" isn't the guidance though - it's a list of passwords exposed in previous breaches. That list can be huge, and only practical to check with some efficient lookup mechanism.
      - Deimorz 9y ago
        Ah okay, sorry. I was thinking about it from the perspective of common passwords since that's something I've tried to find an existing bloom filter for before. I agree with you that Troy would probably be one of the best people to provide something like that. I wonder how feasible it is, that would be a really great resource to have available.
EGreg 9y ago
Or you can move beyond passwords. https://github.com/Qbix/auth https://github.com/Qbix/auth
- striking 9y ago
  The "Specification" section is blank. As much as I hate passwords, I don't think we should get rid of them without replacing them with something else...
  - EGreg 9y ago
    We are still working on the formal spec. However, the overview is totally complete! I just put the link here to get some feedback. This is what replaces the passwords.
xoa 9y ago
While I think there is growing recognition that password based authentication is a highly suboptimal path dependency, we're also stuck with them on the majority of systems/services for the time being. Even if UI and market standards for cryptographic based auth finally gets improved, it'll still be a long haul for it to grow in usage. That being said this seems like a solid overall listing of the basics that all password using services should follow, except as koolba said earlier "Security" Questions (scare-quotes extremely intentional) were always a horrible anti-user & anti-security idea and should be eliminated everywhere. My only actual quibble/concern with this piece is in the "Notify Users of Abnormal Behaviour" section. I agree it's a good idea in principle to perform notifications, the only niggle though is that some common forms of notification are not authenticated in general, and in practice that particularly means email. I have only ever seen a few companies, even in the financial sector, that sign emails (and without that more aggressive automated domain anti-forging is hard too). At least from the stats I've seen on my own servers and for users I'm responsible for, "Notification/Alert" emails are an ever greater favorite of spearphishers & spammers. A lot of the major companies deal with this by using better authenticated purpose-made notification systems or even just text messages, but email still enters in, and if the practice spreads I'd expect to see a lot more places just using email. I think it's worth being careful about getting users trained into any habit that might lead them to immediately assume something from an unauthenticated source is real and should be clicked. This might be an area that'd be worth coming up with better standards and UI for as well.
- pishpash 9y ago
  "While I think there is growing recognition that password based authentication is a highly suboptimal path dependency, we're also stuck with them on the majority of systems/services for the time being." There is a pretty clear path off of it, via physical token authenticated password managers. The only thing missing is a standardized and well popularized protocol for changing passwords.
  - xoa 9y ago
    >There is a pretty clear path off of it, via physical token authenticated password managers. The only thing missing is a standardized and well popularized protocol for changing passwords. I don't think it's that simple. After all, the basic tech to handle this stuff has been around for literally decades at this point. Even in terms of open source, projects like OpenSC date back a decade and a half (2002 or before). The problem has always been in terms of bringing the elements together into a standardized system that has a least a few major implementations with good UI, and gaining critical mass to kick start a virtuous circle of adoption, uptake, demand, and more adoption. It's not a technology problem. I've seen enough hopes raised followed by false starts or even flat out regression that I think it'll be a hard slog, though as the problem is only getting worse I'm hopeful we'll get there eventually. And even more, that once there is at least one good mass example showing people how things could be better there will be mass demand and we'll see a nice S-curve of adoption rather then linear.
wepple 9y ago
I'm curious; why aren't we dropping the use of passwords in favor of U2F? I guess for one; not everyone wants to buy and carry a key. But we're at the point where you have to have a password manager anyhow, a token isn't that much more of a burden.
- ivanbakel 9y ago
  The first general-user services to enforce 2FA of any kind will be sacrificing a massive number of users to do it. As a company running a service for money, you have no incentive to make your system more secure on the user end - obstacles for the user are just users lost. Security-conscious users can push for 2FA on services, but we probably won't hit it being mandatory any time soon.
  - danneu 9y ago
    But if there's any money at stake, then any money exfiltrated from your users is money that you never receive, so there's certainly an incentive but also trade-offs.
    - ivanbakel 9y ago
      Assuming 1. Your profits come directly from your users 2. A password crack can result in them losing a significant amount of money, and 3. This happens often enough that it offsets the userbase losses of 2FA If your user accounts are important enough to let them lose a large amount of money, your users are probably demanding better security from you already. The real blocker to 2FA are services which rely on being convenient, and make money off their users being users e.g. social media.
- IncRnd 9y ago
  > I'm curious; why aren't we dropping the use of passwords in favor of U2F? Well, you are favoring U2F, which is a _specific_ _implementation_ of 2FA. U2F isn't being used generally, because it isn't a general purpose solution. > I guess for one; not everyone wants to buy and carry a key. This statement is the problem with looking at specific implementations to solve a general problem, instead of looking at all the solutions. There are many solutions, not all of which even use physical keys fobs. RSA is a straightforward example of why a 3rd party shouldn't automatically be trusted for auth mechanisms. > But we're at the point where you have to have a password manager anyhow, a token isn't that much more of a burden. The burden isn't just a user side issue about carrying a fob. For general password replacement, key fobs will get lost. Passwords are a burden to the user, having to pay or deal with key fobs and their replacements will be an even greater burden. You are proposing to solve the auth problem by causing many users to stop using websites. Unfortunately, there are also issues with soft tokens. There are still applications that only use the "first soft token" in a list of soft tokens owned by a user. Plus, soft tokens are quite amenable to being copied. There are also many banks and credit card issuers who have consciously chosen various forms of 1.5FA instead of 2FA. In many cases this is a valid solution, a form of dual sided auth that works across all clients.
pishpash 9y ago
A person only has so many memorizable passwords that they can hold at a time; the entropy source is very very low rate. Revealing any memorizable password to stupid random sites is itself an antipattern.
- pault 9y ago
  I use a pass phrase salted with the first n characters in the name of the site, so I only have to remember one password and have unique passwords for all accounts. For example, monkey + ycombinator = myocnokmebyi
aidos 9y ago
On systems that disable the pasting of passwords: could I give a special shout-out to Apple OSX which, in 2017, still refuses to allow users to paste a passphrase when the ssh agent pops up a window to request it?
- ivanhoe 9y ago
  The single most annoying thing in OSX IMHO. However this little script solves the problem: https://github.com/EugeneDae/Force-Paste https://github.com/EugeneDae/Force-Paste
  - deleted 9y ago
    [deleted]
- azag0 9y ago
  Perhaps the reason is to prevent anything from spying on the clipboard. Keyloggers are likely prevented by Secure Keyboard Entry. In contrast, websites cannot spy on clipbaord, so there is not real reason to prevent paste on websites.
  - scott_karana 9y ago
    When Terminal.app itself is in Secure Entry mode, you can still paste, so I don't think your hypothesis is right :/
BlackFly 9y ago
For anyone who is thinking about using unicode for passwords, remember to normalize the unicode before hashing it. Different human input devices may output different codepoints for what appears to a human to be the same character/string. Obviously make sure you manage the decoding/encoding as well.
rietta 9y ago
Excellent read. I've finally decided to do what I've been saying I would do for two years and create an open source demo Ruby on Rails application that applies these principles using the Devise gem and a few others. Will show it supporting multiple two factor strategies as well as account lockout, recovery, and access downgrading based on confidence. It's a private repo at the moment but I will share as soon as its worth showing.
Someone1234 9y ago
I like the concept of "Notify Users of Abnormal Behaviour" but how. I mean that in a technical sense. This XKCD seems to apply[0]. People take for granted that an organisation can just hook into a bunch of paid external services, GeoIP, Browser/Device Database, etc. First off, there's a great many organisations who cannot or will not be able to use an external GeoIP database for example, and even if they could how is a threshold of "abnormal" determined? I too love Facebook's implementation. How do I make that without hooking into half a dozen paid external providers? I'm legitimately asking, because this seems like a "research team and five years" type of issue. [0] https://xkcd.com/1425/ https://xkcd.com/1425/
- raesene6 9y ago
  You can implement a basic level of this just by storing some information about users and then comparing it on login. Some relatively simple examples - Inform users of unsuccessful login attempts since their last sign-in. This can let them know if someone is trying to attack their account. - Notify the user if they login from a new browser. You can record information about the client (user agent plus other identifiers that are visible server-side) and then notify the user when connections are made from new systems that haven't been seen before. - For GeoIP there are basic datasets that cover things like country of origin that are generally available for free. You could use one of those to note the customers general country of origin and then notify when that changes. None of these are flawless of course, but they could provide some basic means to help users protect their accounts.
- NMDaniel 9y ago
  I think this is actually a case for delegated authentication, you can quite simply let Facebook(or Google,MS or some other trusted auth provider) handle these things instead of implementing them yourself. Use some form of social login(OAuth2/OpenID Connect)
utexaspunk 9y ago
Is there an independent body that certifies that a site uses good practices? I mean, I have no way of knowing whether a website is storing my password in the clear (unless they email my password to me), using a symmetric cypher, a site-wide salt, etc. It would be nice if a trustworthy party could investigate a site's security practices and certify that they are doing things properly.
waynecochran 9y ago
Math tells us longer passwords are better than longer alphabets, yet I am often forced to add special characters. If I have 12 character password over an alphabet of 26 characters, there are 26^12 possible passwords. If I have the choice between adding 5 special characters or increasing the length of my password by 5 characters, math says do the latter: (26 + 5)^12 = 7.88 x 10^17 < 26^(12 + 5) = 1.13 x 10^24 That's over six orders of magnitude higher. How come supposedly computer savvy people don't know the difference between x^N and N^x?
- forkerenok 9y ago
  Totally sympathize with your comment, but, playing devils advocate, > 26^12 = 9.542895666×10^16 You could say adding 5 special chars "cheaply" doubles (formally) the search space without affecting how many chars users have to memorize.
  - pishpash 9y ago
    That's not how entropy works. Yes they've expanded the search space, but not how large the typical set is. The latter is still determined by the user's memory habits.
  - waynecochran 9y ago
    Isn't that 5 more characters to memorize? I guess I don't understand.
- pishpash 9y ago
  Who said computer savvy people designed these? These rules are not designed for technical reasons but for security theater.
- dublinben 9y ago
  What makes you think that these composition rules are being set by the computer-savvy folks in the room, not box-checking bureaucrats? No engineer worth his salt would propose any of the terrible password requirements (10 char max, no pasting, etc.) featured in this article.
karrotwaltz 9y ago
Here is what NIST has to say about allowing the user to display the password on screen: > In order to assist the claimant in successfully entering a memorized secret, the verifier SHOULD offer an option to display the secret — rather than a series of dots or asterisks — until it is entered. This allows the claimant to verify their entry if they are in a location where their screen is unlikely to be observed.
ojr 9y ago
No mention of how to authenticate on mobile? I don't think a guidance on how to authenticate for the Modern Era is complete without having a mobile solution
- dublinben 9y ago
  Every decent password manager and 2FA solution is available on mobile.
BucketSort 9y ago
I believe eventually passwords will become cognitive thumbprints. I.e. instead of a password, we play a short game, type in some text of which the cadence can be analysed.
- pishpash 9y ago
  Authenticating against something that cannot be changed but can be counterfeited is a horrible idea. Plus, good luck storing that kind of thing securely.
deleted 9y ago
[deleted]
_nothing 9y ago
Whenever a site requires special characters, it just ends up limiting me to one of the few memorized passwords I have that matches the criteria, most of which are barely 8 characters long. I use LastPass but I don't like using the password generator because I want to be able to log in on mobile or other computers when necessary, but I don't do so enough to justify signing up for a subscription (I dislike subscription models) that would allow me to access use it on mobile. I wish I could just use giant password strings on all of my sites.
- drewmol 9y ago
  Not a huge fan of subscription models, but if using password manager software, it seems like an appropriate pricing model. You expect/demand the software vendor to be consistentsly up to date on best security practice and vulnerability patching. A subscription model gives more incentive to provide this due to the risk of losing future revenue(subscribers & reputation) in the event of a failure.
- snailmailman 9y ago
  You can access lastpass on mobile and desktop without a subscription now
deleted 9y ago
[deleted]
Piccollo 9y ago
I like my passwords 1, 2, 3, and 4 5.
ss248 9y ago
>Embrace Password Managers I disagree. Author pointed out "all eggs in one basket" issue, but it doesn't look like he completely understands the whole problem. The main problem is that passmanager holds a lot of metadata. For example, you use unique password with high entropy for every service you use. Once attacker gets your one master password (through zero-day or just by watching you type it), potential damage is massive. He doesn't have to try to find where you are registered, password manager will tell everything, about every single account and possibly more; some people even store credit card/banking info in passmanager. At that point it's over, you lost. "... if (password manager) gets compromised it's going to be bad news. But this is an exceptionally rare event compared to the compromise of an individual service which consequently exposes credentials." This is not an argument at all. Let's consider the situation when individual service gets compromised. Attacker has thousands of salted hashes. With good hash algorithm, he have to spend considerable amount of time cracking every single hash. He doesn't target you in particular. You are just one of many. If attacker cares about you, after cracking hash and getting your password, he has to do a lot of research (trying to find other sites where you used that password and hope you didn't change anything there) to make any use of it. Objectively, he doesn't actually have much. So going after popular services you use, just to get your password, doesn't look like a good attack vector in the first place. People should know, that password manager is just a glorified notepad file with one password. By using them you are trading safety in situations when attacker targets you, for safety in situations when attacker targets someone else and you are just a collateral damage. If you must, use them only for information you don't care to lose.
- squaredpants 9y ago
  What about a Password Manager combined with 2FA? A bit of redundancy in case your master password is somehow compromised, so that you can individually still change each websites' passwords and store them in a new password manager with a different master password. The same applies if your 2FA device is stolen, you may store their recovery passwords on a separate password manager that isn't accessed as often.
  - ss248 9y ago
    What kind of "2FA"? SMS 2FA is not secure. Stand-alone device for every single service? Secure, but acquiring one is not so simple and not every service provides them. And do you really need to bother with multiple passmanagers at that point? Just store accounts you don't care about in one. For accounts you really care about, you should make strong unique password yourself and use stand-alone 2FA device.
brightball 9y ago
When I talk about security, the question I like to pose is this: Imagine every password for every one of your users is published...can you identify people? How would you clean up the mess? Imagine a malicious person logged into EVERY one of your user accounts and tampered with them, changed email addresses, etc. Can you identify it? Can you clean it up? Can you prevent it from happening again? If the answer to any of those is no...then you're sitting on a time bomb. Start with the assumption that the username and password is convenient but unreliable, then move forward with actual security.
iooi 9y ago
What is the consensus on not allowing previously used passwords? i.e., when changing your password: "You used this password too recently, you can not use your last 20 passwords"
- smichel17 9y ago
  I am not a security expert; I'm sharing my experience, not attempting to answer the question. Back before I used a good password manager setup, I used a mental algorithm of [base password] + per-site modifications. These were saved in Firefox and I'd sometimes forget them when I wasn't on my normal device. If I needed to get on to a service (eg, email) whose password I'd forgotten, I'd reset it, then reset again, back to what it was, when I got back to a place it was saved. At some point, gmail prohibited this, and I had to update all my passwords whenever I needed to reset. The result was the same as forced password rotation: I just started using more memorable (less secure) passwords. That said, there's definitely measures Google could take to mitigate this effect. For example, drawing from the article, there could be tiered access control, where one tier (eg, 2fa but no pw) lets me get some limited access without changing the password. Then there would be no legitimate reason for returning to an old password, so such a policy is not harmful.
- technion 9y ago
  The policy of not allowing previous passwords exists in the first place to ensure password rotations really happen. I've been in organisations where you tell people that passwords change every thirty days, and they say "that's ok, I'll just change it and then change it back". Why do I need to change passwords every thirty days? Because it's one of only three questions our risk assessment auditors actually ask, and "failing" is bad news. If we accept we don't need to rotate passwords arbitrarily, there's no reason to have rules like this - it's more secure and less effort to not retain the last 20 passwords.
dustinmoris 9y ago
One thing which I find Troy constantly misses to advertise and which I personally think is a much better solution than using password managers and each individual system having to develop their own login + verification and security system is to use 3rd parties to authenticate. I am a big fan of password managers, but I don't think there is a need for them, because WE ALREADY HAVE ALL OUR EGGS IN ONE BASKET: email. If someone gets access to your email address then they have effectively access to every single service you signed up with that email. Therefore every single service might as well just use Google/Hotmail/Microsoft/etc. to authenticate their users instead of building their own login system and asking people to come up with a new password which forces them effectively to use a password manager and yet another place to store all eggs in one basket. The password to your email account == the password to your password manager. If we would all just rely on Google/Hotmail/Microsoft/Facebook logins then we would be even more secure then everyone having to use a password manager, and it would be a much better user experience. Also I am pretty sure that Google + Microsoft + Facebook have a lot more talent + resources to secure their accounts then every new service which pops up every day. Let them do the security and you focus on your actual business value...
- CM30 9y ago
  This has numerous problems though: 1. Not everyone uses those email services. Indeed, for a certain subset of users (especially on technical forums like Hacker News), using them is seen as opening yourself up to unwanted surveillance. This means tech forums relying on such a system are potentially driving away a decent portion of their userbase. 2. Not everyone wants to use the same account details. For instance, if I join a site with a more professional audience, my current username (and my email one) may come across as awkward or robotic. If I join a fan forum, I might want a username based on the game or show. Etc. 3. A lot of people want to keep their online identities seperate for security reasons. I mean, do you really want to use the same email for a dating site as you do your bank? Not really, but tying the login systems of each site to Gmail or the likes means you've either compromised said privacy or given yourself another Gmail/Hotmail account to memorise the details for. 4. It encourages centralisation. We've already got a problem with a few large services having an untoward amount of influence online, and having their login systems used for numerous other sites only makes that worse. It means if they decide your site is against the rules or 'hate speech', your users can't log in. So nah, I'd rather sites didn't use third party authentication. It has too many drawbacks.

440 points by Spydar007 9y ago

The problem with a password manager is that you don't have easy access to one when you're on a different machine. A better way is to use a scheme that hashes your username, service name, and master password to generate a password. A problem is that this doesn't always comply with the arbitrary demands on your password. This is why these arbitrary demands need to die: they make the only way to securely and conveniently access accounts from different devices impossible.

wutwutwutwut 9y ago
Your suggestion is bad for a ton of reasons. For example, how do you change your password for a specific site after it had been compromised or due to normal password rotation? Another downside is that changing master password means you need to change passwords for all sites or have multiple master passwords. Another is that an attacker can use the knowledge of your password on site A to bruteforce your master password offline. And so on...
- l0b0 9y ago
  Why on earth is this being downvoted? If you've used a hashing generator for any length of time you'll know how multiple master passwords inevitably creep in. Also, when your generator no longer works because the login FQDN changes (which happens alarmingly often) you'll have all the fun of resetting your password. For no good reason. Re. portability, KeePass and its siblings are compatible with every major platform.
  - Globz 9y ago
    I have access to my password manager at all time, thanks to https://minikeepass.github.io/ https://minikeepass.github.io/ on iOS! You can even sync your database to all of your devices by storing it inside an encrypted volume for extra security.
    - kutkloon7 9y ago
      Does this also work when you use someone else's phone or computer?
- Lagged2Death 9y ago
  ...an attacker can use the knowledge of your password on site A to bruteforce your master password offline. This might be a concern if you're the victim of a state-level targeted attack. That's not a threat most of us have to deal with. Hackers aren't likely to spend a lot of effort cracking John Doe's password list; they want to steal a few million password hashes and sift out a few thousand easy or re-used ones. Your other points about the weaknesses of the scheme stand. Still, if we could get more users to use not-terrible, not-duplicated passwords, even with a flawed scheme like this, overall internet security would improve immeasurably.
  - dublinben 9y ago
    You don't need to be the victim of a state-level targeted attack. You just need to be a public figure online[0] and attract the attention of a bored hacker. [0] https://www.theverge.com/2012/8/6/3224597/mat-honan-hacked-apple-icloud-google-twitter https://www.theverge.com/2012/8/6/3224597/mat-honan-hacked-a...
    - Lagged2Death 9y ago
      I'm not super familiar with the Honan story but I recall (and quick skimming seems to confirm) that it was more about lax security policies at Apple et al, the interconnectedness of social media accounts, and social engineering than it was about reversing a computed hash or human "hashing" scheme. Did those attackers guess or compute even one password at all?
      - dublinben 9y ago
        Not in this specific instance, but they could have. And that level of scrutiny would have enabled a complete digital takeover like Honan suffered if his accounts were poorly protected by a system of passwords proposed above.
  - IncRnd 9y ago
    This is false. There are many types of targeted attacks on passwords that don't come close to including state-level actors. Divorces. Corporate Espionage. Any one of the people on Judge Judy who posted information online about their co-workers.
- kutkloon7 9y ago
  You can add something (e.g. a number) to the end to make a different password. The idea is that you have a _very_ secure master password (so bruteforcing it is not practical - to make this even more true you could hash a huge number of times instead of just once) and never change it. There is still some truth in your arguments. I'm curious what you consider a good alternative?
notzorbo3 9y ago
> hashes your username, service name, and master password Security through obscurity. You're essentially just using the same password on every site now.
- dspillett 9y ago
  Ish. If you use a sufficiently good hash function with a salt to stop rainbow table based attacks and key strengthening for good measure, then an attacker who has one compromised password of yours isn't going to be able to reverse the hash to find what your source password is so that they can generate new per-site passwords using it. That is assuming they even try: how would you know that an arbitrary string of characters was generated that way rather than just being randomly picked by a password manager? Of course all your accounts are compromised if someone knows your master password, but that is little different to an attacker getting your pass-word/-phrase for an online password manager that doesn't use some form of 2FA.
  - IncRnd 9y ago
    No. This is not a cryptographic attack on the hash but on the text that is being hashed.
    - dspillett 9y ago
      But how would the text being hashed be attacked without either attacking the hash by brute force or knowing the master password (which is likely a human factors hack, to which online password managers are similarly susceptible?
      - IncRnd 9y ago
        Using hash functions in an attack is not the same as performing a cryptographic attack against the hash function. These are two different classes of attacks, both being real-world attacks. The attack being discussed is against a suggested formula to generate passwords. From the top of the thread, "a scheme that hashes your username, service name, and master password to generate a password." Discovering the password by determining the inputs to the hash function is all that is needed. This is the case even if a different type of function is used instead of a hash. Apologies, if I gave a different impression.
kijin 9y ago
How often do you need to type passwords into a machine that you either cannot or are unwilling to sync with a decent password manager? How do you trust this machine not to record and exfiltrate everything you ever typed into it? IMO it's a Good Thing (tm) that I have to jump through hoops to access my passwords on unfamiliar machines. How does one even calculate H(username|service name|master password) on an unfamiliar machine that might not have a decent scripting language installed on it? If you asked me to do it on my father's laptop, for example, I'm gonna have to download Python first.
- Sniperfish 9y ago
  Re. the number of machines, it's something I've encountered as an obstacle from a fair proportion of people I've spoken about password managers to. I think its more a perceived issue than a real one. Just spitballing which systems I would realistically want access to passwords on, at a minimum, includes: personal desktop, personal laptop, tablet(s), cellphone(s), family (parent, sibling, in-laws, etc) computers, office desktop, office laptop. In my case (many cases?), the latter two prevent software installation, so I would need to manually type from a manager synced on my cell. Which really is no different to what is required for 2FA - just a longer character string. Overall, a some setup and synch related inconveniences but not to a damaging degree, which is why I think this is more a matter of perception - once you think through where you're typing passwords it appears less of an obstacle.
  - darylfritz 9y ago
    > the [office computers] prevent software installation, so I would need to manually type from a manager synced on my cell. I don't know about other Password Managers, but LastPass lets you access your vault using any web browser. So long as your network doesn't block the LP site, you can access your password manager from anywhere.
    - NMDaniel 9y ago
      On a similar note, Keepass can be used without admin rights with the portable version, so you can keep the portable executable along with the encrypted db file in some secure and accessible email account/web service that your network doesn't block.
deleted 9y ago
[deleted]
blowski 9y ago
Most of my passwords never need to be typed onto strange machines, so I can use 1Password with long random complex strings. If it is a password I need to type, I use diceware "Correct Battery Horse Staple" style passwords. If I don't remember the password, I always have my phone, where I can retrieve the password from 1Password. There is no relationship between my different passwords. As long as my password vault is secure, so are all my passwords. With your system, if I learn your master password and hashing mechanism, I basically have all your passwords.
- notzorbo3 9y ago
  FYI, diceware has been shown to be insecure with three words. Four is better, but also crackable by an attacker with a few thousand dollars to throw at it. Five and up is safe for the next few years.
- kutkloon7 9y ago
  True! So you have to choose a good master password and use an expensive hash. On the other hand, if you take any other approach, you place either confidence in the security of a service (1password), or you store passwords somewhere. In both cases, you have a problem when you can not retrieve the passwords anymore. If 1password is hacked or simply offline, or your phone gets stolen, you basically lost access to all services.
IncRnd 9y ago
> A better way is to use a scheme that hashes your username, service name, and master password to generate a password. A problem is that this doesn't always comply with the arbitrary demands on your password. This is a very bad mechanism to create passwords that will create severe security vulnerabilities. You are adding complexity and false-security without benefit. Passwords are a secrecy mechanism, not a formula mechanism. In your method, all one needs is the formula, then all passwords will be disclosed. The suggestion might then be to interject a secret with enough entropy into the text being hashed. But, that is no different from a secret password itself!
davchana 9y ago
I have to mine all the time, on my phone, KeepassToAndroid app. Its synced one way (PC to Phone) via dropbox, so that I can edit database only on PC.
0xffff2 9y ago
While I don't particularly like this approach, there's at least one product that does just this: https://lesspass.com/#/ https://lesspass.com/#/

shadowashe 9y ago

passwords are clearly still a gigantic problem in infosec for the users https://blog.binaryedge.io/2017/07/24/antipublic-password-analysis/ https://blog.binaryedge.io/2017/07/24/antipublic-password-an...

dspillett 9y ago
On a quick scan that looks like interesting analysis. Though one point that I find most run-downs like that miss is the number of accounts that are throw-aways, where the user simply doesn't care and will never use it again. At that point using "123456" or "password" isn't an issue, anyone who hacks the account gets nothing more than they would get if they just created a throw-away account themselves.
- codinghorror 9y ago
  The hacker can grief / spam everyone else in the system from this "normal" account. Depends how much public interaction / content posting there is, though.
  - DownGoat 9y ago
    True, but this is not really a problem for the user, but a problem for the system. It is reasonable to assume that the user that creates these type of accounts does not really care about the security of the system either.
deleted 9y ago
[deleted]

gourou 9y ago

https://www.xkcd.com/936/ https://www.xkcd.com/936/

dspillett 9y ago
Somewhat redundant as that is actually referenced by the article itself, both as a general discussion point regarding passphrases/passwords and specifically because that specific string is actually found a number of times in the reference data sets.

gourou 9y ago

https://www.baekdal.com/insights/password-security-usability https://www.baekdal.com/insights/password-security-usability

tomp 9y ago

Ah, passwords. Look, webmasters, the simple truth is - I don't care. I have a default password that is very simple to memorise (and hence guess/hack), that I use for most logins, because frankly, I just don't care. Unless you're vitally important to my life (email, Facebook, backup, services that I use so often that they keep my personal/credit card data), your login/password is just an annoyance for me, as is your password security policy. I commend reddit and webshops that allow "checkout as guest", that recognise this.

Analemma_ 9y ago
You really should be using a password manager then. You still only have to memorize one password, but you’re not severely compromising your security anymore.
- TeMPOraL 9y ago
  Parent's point is that they don't care. It's not their security being compromised, but the site's. There are plenty of sites out there with unnecessary registration requirements. I don't mind setting a weak, throwaway password on those.
  - BlackFly 9y ago
    Don't forget to use a throwaway email account! Lot's of good email providers give temporary aliases for this reason.
    - msla 9y ago
      I like Spam Gourmet: https://www.spamgourmet.com/index.pl https://www.spamgourmet.com/index.pl
  - naasking 9y ago
    > Parent's point is that they don't care. It's not their security being compromised, but the site's. He'll care plenty if his hacked account posts a threat against the president and he gets a visit from the secret service.

koolba 9y ago

This is a nice article. Only thing missing is calling out "secret questions" as asinine. I loathe when sites require you to set them up as it requires manually generating a series of N-length random strings (ex: eZDWzazuMw0ZzD4nKhxXXVN3) and saving the pair (question plus random text) as metadata associated with the account. Not exactly pulling teeth but it's pretty annoying to manually do that for 3-5 entries. Even worse offenders are the sites that don't even let you enter a value in a text box but instead require you to pick from a drop down with a handful, say 10-15, of entries (cough United Airlines cough). And the very worst offenders are the ones that, after successfully authenticating with your password, ask you for the answers to the secret questions every single time you log in (cough again United Airlines cough).

aczerepinski 9y ago
It's nearly impossible to remember what you answered for those questions anyway. For first car did I write "Ford", "ford", "Focus", "Ford Focus", etc? I don't have a specific favorite movie or song. Lord knows what I entered into one of those boxes a year or two ago. Whatever it was, I bet it wasn't as secure as my password.
- thinkfurther 9y ago
  > For first car did I write "Ford", "ford", "Focus", "Ford Focus", etc? No biggie, the person telling you at length about the quirks of their first car until you mention what your first car was will happily try them all.
  - rockostrich 9y ago
    One of the questions my bank asks is what middle school I went to and I used my elementary school by mistake. I just listed every school I went to to the guy on the phone when trying to unlock my account. It's a good thing they also ask for SSN/amount previously in the account/who your last check was made out to and that sort of thing.
    - deleted 9y ago

MarkMc 9y ago

This is a great article, but it doesn't acknowledge that there is sometimes a tradeoff between security and profit. For example, imagine a typical user who tries to choose a password: User: I want my password to be "monkey" System: Sorry, that password is in the dictionary User: OK, I want my password to be "monkey1" System: Sorry, that password is on a list of exposed passwords User: Grrr! OK, I want my password to be "monkeymonkey" System: Sorry, that password is on a list of exposed passwords User: Grrr! OK, I want my password to be "monkeyfuckyou!!!" System: Sorry, that password is on a list of exposed passwords User: Screw this, I'll just sign up with one of your competitors.

shandor 9y ago
The real problem relating to "profit" in these cases is that companies are not penalized at all for leaking their users' secrets, not the fact that security has "tradeoffs". Software industry is in the same boat regarding this as car manufacturers were decades ago, i.e. it was "more profitable" to make cars that killed their passengers in every other car crash, since people were just making the very rational choice of buying the cheaper rather than safer car.
weinzierl 9y ago
It's a usability nightmare. I played a bit with password crackers recently and to me it is still often completely counterintuitive which passwords are easy to crack and which are not. Now good luck explaining that to your users without frustrating them. Take for example '_=$%=_$ _ !'. Why is that a bad password? Because it's in one of the common wordlists (yes, it has two spaces and no, I didn't make that up). That's why I think there should be more focus on the point that users should never produce passwords themselves, but leave that job to a good random generator. This is also something I missed from Troy's otherwise excellent article. What is the point of using a password manager if you only use it to store your weak passwords? I also believe the argument about passwords being memorable is a red herring. It is possible to remember a low number of sufficiently long truly random passwords. It takes effort and it is risky, but it is not impossible. Producing a good password without the help of a random generator on the other hand is simply impossible.

SeoxyS 9y ago

One thing that bothers me about this article, and the way everyone does passwords is this assumption that the output of a cryptographic had function is alphanumeric. It's not, is binary. Store the actual data in your database, not the base16 representation! This applies to anything, not just passport hashes—don't transmit around data as base64 unless you're actually using a medium that requires it (e.g. email)

GordonS 9y ago
What's the issue with storing password hashes encoded as base64?
- arethuza 9y ago
  It's going to be a third bigger than storing the bytes directly - which doesn't seem that big a deal. Storing images or video base64 encoded in a database columns would be silly but for hash values I'd be inclined to go for something that is slightly easier to code against.
- zimbatm 9y ago
  It's unnecessary CPU work and also takes more storage space in the database. In practice I doubt that it makes much difference in terms of performance as hashing is way more expensive than base64-encoding. The rant is probably more against the misunderstanding of developers.
- yourapostasy 9y ago
  Good question, I'd like to know SeoxyS's reason, too. Aside from the space consideration already mentioned, if I had to surmise, I'd guess it would be faster to process because we're skipping the encode/decode steps unless we are explicitly "importing" or "exporting" the hash, and less chance of making mistakes to encode/decode through Base64 before doing anything with the hash. It is marginally more of a hassle to debug in a live production environment, though. When you are troubleshooting, grabbing the binary representation and running it through a Base64 decoder is annoying. Doing this from inside a mass file search to look for all instances of the same hash can be a bother. I suspect we're storing as Base64 everywhere because so many hashes are held in XML files, and the standard strongly encourages storing binary within XML as Base64. Once they are doing it in an XML file somewhere, I gather lots of teams make that the canonical representation everywhere, even in a database when it isn't strictly necessary.

jimktrains2 9y ago

The problem with passwords on the web is that they require sending and trusting private credentials to someone else. As devs we need to working on making better systems (e.g. TLS client certs and SRP (e.g. TLS-SRP or PAKE)) more usable. It's not a magic bullet and not something a switch can be flipped on, but the status quo is terrible.

IshKebab 9y ago
Or OAuth.
- wedowhatwedo 9y ago
  Not the current OAuth. It is different for each provider. The standard isn't strict enough. I have to write something special each implementation I want to use. The standard needs to be modified so every implementation works exactly the same way - then I'd say OAuth would be a good potential solution.
- jimktrains2 9y ago
  The provider of an oauth endpoint normally still requires you to send your private credentials. It also ties a lot of identities together making it not Angkor solution for many people.
dublinben 9y ago
Like U2F?
- jimktrains2 9y ago
  U2F is definitely nice, but it's impracticle to expect everyone to have a hardware key. There are software only wins that can be much better than the current status quo. Sure, you can gave software U2F keys, but that's not commor or expected from what I understand.
  - ptoomey3 9y ago

zwily 9y ago

Does anyone provide a regularly updated bloom filter of exposed passwords you could use for meeting the last point? Seems like something Troy could do...

welder 9y ago
If it's for your website, start by adding a password strength meter using zxcvbn[1]. For example: https://github.com/MorrisJobke/strengthify https://github.com/MorrisJobke/strengthify [1]: https://github.com/dropbox/zxcvbn https://github.com/dropbox/zxcvbn
jdormit 9y ago
Do you think the chances of false positives would make a bloom filter a bad choice for this?
- Deimorz 9y ago
  It's not ideal, but shouldn't be a big issue, since a false positive just means that you (very rarely) tell a user that a password is unacceptable when it should have been fine. That's a bit annoying for the user, but the result is that they just end up picking a different secure password. False negatives would be worse. Really though, a list of common passwords to block is such a small amount of data that it's probably best to just use an exact list. I can't see it being more than a megabyte or so.
  - zwily 9y ago
    A "list of common passwords" isn't the guidance though - it's a list of passwords exposed in previous breaches. That list can be huge, and only practical to check with some efficient lookup mechanism.
    - Deimorz 9y ago
      Ah okay, sorry. I was thinking about it from the perspective of common passwords since that's something I've tried to find an existing bloom filter for before. I agree with you that Troy would probably be one of the best people to provide something like that. I wonder how feasible it is, that would be a really great resource to have available.

EGreg 9y ago

Or you can move beyond passwords. https://github.com/Qbix/auth https://github.com/Qbix/auth

striking 9y ago
The "Specification" section is blank. As much as I hate passwords, I don't think we should get rid of them without replacing them with something else...
- EGreg 9y ago
  We are still working on the formal spec. However, the overview is totally complete! I just put the link here to get some feedback. This is what replaces the passwords.

xoa 9y ago

While I think there is growing recognition that password based authentication is a highly suboptimal path dependency, we're also stuck with them on the majority of systems/services for the time being. Even if UI and market standards for cryptographic based auth finally gets improved, it'll still be a long haul for it to grow in usage. That being said this seems like a solid overall listing of the basics that all password using services should follow, except as koolba said earlier "Security" Questions (scare-quotes extremely intentional) were always a horrible anti-user & anti-security idea and should be eliminated everywhere. My only actual quibble/concern with this piece is in the "Notify Users of Abnormal Behaviour" section. I agree it's a good idea in principle to perform notifications, the only niggle though is that some common forms of notification are not authenticated in general, and in practice that particularly means email. I have only ever seen a few companies, even in the financial sector, that sign emails (and without that more aggressive automated domain anti-forging is hard too). At least from the stats I've seen on my own servers and for users I'm responsible for, "Notification/Alert" emails are an ever greater favorite of spearphishers & spammers. A lot of the major companies deal with this by using better authenticated purpose-made notification systems or even just text messages, but email still enters in, and if the practice spreads I'd expect to see a lot more places just using email. I think it's worth being careful about getting users trained into any habit that might lead them to immediately assume something from an unauthenticated source is real and should be clicked. This might be an area that'd be worth coming up with better standards and UI for as well.

pishpash 9y ago
"While I think there is growing recognition that password based authentication is a highly suboptimal path dependency, we're also stuck with them on the majority of systems/services for the time being." There is a pretty clear path off of it, via physical token authenticated password managers. The only thing missing is a standardized and well popularized protocol for changing passwords.
- xoa 9y ago
  >There is a pretty clear path off of it, via physical token authenticated password managers. The only thing missing is a standardized and well popularized protocol for changing passwords. I don't think it's that simple. After all, the basic tech to handle this stuff has been around for literally decades at this point. Even in terms of open source, projects like OpenSC date back a decade and a half (2002 or before). The problem has always been in terms of bringing the elements together into a standardized system that has a least a few major implementations with good UI, and gaining critical mass to kick start a virtuous circle of adoption, uptake, demand, and more adoption. It's not a technology problem. I've seen enough hopes raised followed by false starts or even flat out regression that I think it'll be a hard slog, though as the problem is only getting worse I'm hopeful we'll get there eventually. And even more, that once there is at least one good mass example showing people how things could be better there will be mass demand and we'll see a nice S-curve of adoption rather then linear.

wepple 9y ago

I'm curious; why aren't we dropping the use of passwords in favor of U2F? I guess for one; not everyone wants to buy and carry a key. But we're at the point where you have to have a password manager anyhow, a token isn't that much more of a burden.

ivanbakel 9y ago
The first general-user services to enforce 2FA of any kind will be sacrificing a massive number of users to do it. As a company running a service for money, you have no incentive to make your system more secure on the user end - obstacles for the user are just users lost. Security-conscious users can push for 2FA on services, but we probably won't hit it being mandatory any time soon.
- danneu 9y ago
  But if there's any money at stake, then any money exfiltrated from your users is money that you never receive, so there's certainly an incentive but also trade-offs.
  - ivanbakel 9y ago
    Assuming 1. Your profits come directly from your users 2. A password crack can result in them losing a significant amount of money, and 3. This happens often enough that it offsets the userbase losses of 2FA If your user accounts are important enough to let them lose a large amount of money, your users are probably demanding better security from you already. The real blocker to 2FA are services which rely on being convenient, and make money off their users being users e.g. social media.
IncRnd 9y ago
> I'm curious; why aren't we dropping the use of passwords in favor of U2F? Well, you are favoring U2F, which is a _specific_ _implementation_ of 2FA. U2F isn't being used generally, because it isn't a general purpose solution. > I guess for one; not everyone wants to buy and carry a key. This statement is the problem with looking at specific implementations to solve a general problem, instead of looking at all the solutions. There are many solutions, not all of which even use physical keys fobs. RSA is a straightforward example of why a 3rd party shouldn't automatically be trusted for auth mechanisms. > But we're at the point where you have to have a password manager anyhow, a token isn't that much more of a burden. The burden isn't just a user side issue about carrying a fob. For general password replacement, key fobs will get lost. Passwords are a burden to the user, having to pay or deal with key fobs and their replacements will be an even greater burden. You are proposing to solve the auth problem by causing many users to stop using websites. Unfortunately, there are also issues with soft tokens. There are still applications that only use the "first soft token" in a list of soft tokens owned by a user. Plus, soft tokens are quite amenable to being copied. There are also many banks and credit card issuers who have consciously chosen various forms of 1.5FA instead of 2FA. In many cases this is a valid solution, a form of dual sided auth that works across all clients.

pishpash 9y ago

A person only has so many memorizable passwords that they can hold at a time; the entropy source is very very low rate. Revealing any memorizable password to stupid random sites is itself an antipattern.

pault 9y ago
I use a pass phrase salted with the first n characters in the name of the site, so I only have to remember one password and have unique passwords for all accounts. For example, monkey + ycombinator = myocnokmebyi

aidos 9y ago

On systems that disable the pasting of passwords: could I give a special shout-out to Apple OSX which, in 2017, still refuses to allow users to paste a passphrase when the ssh agent pops up a window to request it?

ivanhoe 9y ago
The single most annoying thing in OSX IMHO. However this little script solves the problem: https://github.com/EugeneDae/Force-Paste https://github.com/EugeneDae/Force-Paste
- deleted 9y ago
  [deleted]
azag0 9y ago
Perhaps the reason is to prevent anything from spying on the clipboard. Keyloggers are likely prevented by Secure Keyboard Entry. In contrast, websites cannot spy on clipbaord, so there is not real reason to prevent paste on websites.
- scott_karana 9y ago
  When Terminal.app itself is in Secure Entry mode, you can still paste, so I don't think your hypothesis is right :/

BlackFly 9y ago

For anyone who is thinking about using unicode for passwords, remember to normalize the unicode before hashing it. Different human input devices may output different codepoints for what appears to a human to be the same character/string. Obviously make sure you manage the decoding/encoding as well.

rietta 9y ago

Excellent read. I've finally decided to do what I've been saying I would do for two years and create an open source demo Ruby on Rails application that applies these principles using the Devise gem and a few others. Will show it supporting multiple two factor strategies as well as account lockout, recovery, and access downgrading based on confidence. It's a private repo at the moment but I will share as soon as its worth showing.

Someone1234 9y ago

I like the concept of "Notify Users of Abnormal Behaviour" but how. I mean that in a technical sense. This XKCD seems to apply[0]. People take for granted that an organisation can just hook into a bunch of paid external services, GeoIP, Browser/Device Database, etc. First off, there's a great many organisations who cannot or will not be able to use an external GeoIP database for example, and even if they could how is a threshold of "abnormal" determined? I too love Facebook's implementation. How do I make that without hooking into half a dozen paid external providers? I'm legitimately asking, because this seems like a "research team and five years" type of issue. [0] https://xkcd.com/1425/ https://xkcd.com/1425/

raesene6 9y ago
You can implement a basic level of this just by storing some information about users and then comparing it on login. Some relatively simple examples - Inform users of unsuccessful login attempts since their last sign-in. This can let them know if someone is trying to attack their account. - Notify the user if they login from a new browser. You can record information about the client (user agent plus other identifiers that are visible server-side) and then notify the user when connections are made from new systems that haven't been seen before. - For GeoIP there are basic datasets that cover things like country of origin that are generally available for free. You could use one of those to note the customers general country of origin and then notify when that changes. None of these are flawless of course, but they could provide some basic means to help users protect their accounts.
NMDaniel 9y ago
I think this is actually a case for delegated authentication, you can quite simply let Facebook(or Google,MS or some other trusted auth provider) handle these things instead of implementing them yourself. Use some form of social login(OAuth2/OpenID Connect)

utexaspunk 9y ago

Is there an independent body that certifies that a site uses good practices? I mean, I have no way of knowing whether a website is storing my password in the clear (unless they email my password to me), using a symmetric cypher, a site-wide salt, etc. It would be nice if a trustworthy party could investigate a site's security practices and certify that they are doing things properly.

waynecochran 9y ago

Math tells us longer passwords are better than longer alphabets, yet I am often forced to add special characters. If I have 12 character password over an alphabet of 26 characters, there are 26^12 possible passwords. If I have the choice between adding 5 special characters or increasing the length of my password by 5 characters, math says do the latter: (26 + 5)^12 = 7.88 x 10^17 < 26^(12 + 5) = 1.13 x 10^24 That's over six orders of magnitude higher. How come supposedly computer savvy people don't know the difference between x^N and N^x?

forkerenok 9y ago
Totally sympathize with your comment, but, playing devils advocate, > 26^12 = 9.542895666×10^16 You could say adding 5 special chars "cheaply" doubles (formally) the search space without affecting how many chars users have to memorize.
- pishpash 9y ago
  That's not how entropy works. Yes they've expanded the search space, but not how large the typical set is. The latter is still determined by the user's memory habits.
- waynecochran 9y ago
  Isn't that 5 more characters to memorize? I guess I don't understand.
pishpash 9y ago
Who said computer savvy people designed these? These rules are not designed for technical reasons but for security theater.
dublinben 9y ago
What makes you think that these composition rules are being set by the computer-savvy folks in the room, not box-checking bureaucrats? No engineer worth his salt would propose any of the terrible password requirements (10 char max, no pasting, etc.) featured in this article.

karrotwaltz 9y ago

Here is what NIST has to say about allowing the user to display the password on screen: > In order to assist the claimant in successfully entering a memorized secret, the verifier SHOULD offer an option to display the secret — rather than a series of dots or asterisks — until it is entered. This allows the claimant to verify their entry if they are in a location where their screen is unlikely to be observed.

ojr 9y ago

No mention of how to authenticate on mobile? I don't think a guidance on how to authenticate for the Modern Era is complete without having a mobile solution

dublinben 9y ago
Every decent password manager and 2FA solution is available on mobile.

BucketSort 9y ago

I believe eventually passwords will become cognitive thumbprints. I.e. instead of a password, we play a short game, type in some text of which the cadence can be analysed.

pishpash 9y ago
Authenticating against something that cannot be changed but can be counterfeited is a horrible idea. Plus, good luck storing that kind of thing securely.

deleted 9y ago

[deleted]

_nothing 9y ago

Whenever a site requires special characters, it just ends up limiting me to one of the few memorized passwords I have that matches the criteria, most of which are barely 8 characters long. I use LastPass but I don't like using the password generator because I want to be able to log in on mobile or other computers when necessary, but I don't do so enough to justify signing up for a subscription (I dislike subscription models) that would allow me to access use it on mobile. I wish I could just use giant password strings on all of my sites.

drewmol 9y ago
Not a huge fan of subscription models, but if using password manager software, it seems like an appropriate pricing model. You expect/demand the software vendor to be consistentsly up to date on best security practice and vulnerability patching. A subscription model gives more incentive to provide this due to the risk of losing future revenue(subscribers & reputation) in the event of a failure.
snailmailman 9y ago
You can access lastpass on mobile and desktop without a subscription now

deleted 9y ago

[deleted]

Piccollo 9y ago

I like my passwords 1, 2, 3, and 4 5.

ss248 9y ago

>Embrace Password Managers I disagree. Author pointed out "all eggs in one basket" issue, but it doesn't look like he completely understands the whole problem. The main problem is that passmanager holds a lot of metadata. For example, you use unique password with high entropy for every service you use. Once attacker gets your one master password (through zero-day or just by watching you type it), potential damage is massive. He doesn't have to try to find where you are registered, password manager will tell everything, about every single account and possibly more; some people even store credit card/banking info in passmanager. At that point it's over, you lost. "... if (password manager) gets compromised it's going to be bad news. But this is an exceptionally rare event compared to the compromise of an individual service which consequently exposes credentials." This is not an argument at all. Let's consider the situation when individual service gets compromised. Attacker has thousands of salted hashes. With good hash algorithm, he have to spend considerable amount of time cracking every single hash. He doesn't target you in particular. You are just one of many. If attacker cares about you, after cracking hash and getting your password, he has to do a lot of research (trying to find other sites where you used that password and hope you didn't change anything there) to make any use of it. Objectively, he doesn't actually have much. So going after popular services you use, just to get your password, doesn't look like a good attack vector in the first place. People should know, that password manager is just a glorified notepad file with one password. By using them you are trading safety in situations when attacker targets you, for safety in situations when attacker targets someone else and you are just a collateral damage. If you must, use them only for information you don't care to lose.

squaredpants 9y ago
What about a Password Manager combined with 2FA? A bit of redundancy in case your master password is somehow compromised, so that you can individually still change each websites' passwords and store them in a new password manager with a different master password. The same applies if your 2FA device is stolen, you may store their recovery passwords on a separate password manager that isn't accessed as often.
- ss248 9y ago
  What kind of "2FA"? SMS 2FA is not secure. Stand-alone device for every single service? Secure, but acquiring one is not so simple and not every service provides them. And do you really need to bother with multiple passmanagers at that point? Just store accounts you don't care about in one. For accounts you really care about, you should make strong unique password yourself and use stand-alone 2FA device.

brightball 9y ago

When I talk about security, the question I like to pose is this: Imagine every password for every one of your users is published...can you identify people? How would you clean up the mess? Imagine a malicious person logged into EVERY one of your user accounts and tampered with them, changed email addresses, etc. Can you identify it? Can you clean it up? Can you prevent it from happening again? If the answer to any of those is no...then you're sitting on a time bomb. Start with the assumption that the username and password is convenient but unreliable, then move forward with actual security.

iooi 9y ago

What is the consensus on not allowing previously used passwords? i.e., when changing your password: "You used this password too recently, you can not use your last 20 passwords"

smichel17 9y ago
I am not a security expert; I'm sharing my experience, not attempting to answer the question. Back before I used a good password manager setup, I used a mental algorithm of [base password] + per-site modifications. These were saved in Firefox and I'd sometimes forget them when I wasn't on my normal device. If I needed to get on to a service (eg, email) whose password I'd forgotten, I'd reset it, then reset again, back to what it was, when I got back to a place it was saved. At some point, gmail prohibited this, and I had to update all my passwords whenever I needed to reset. The result was the same as forced password rotation: I just started using more memorable (less secure) passwords. That said, there's definitely measures Google could take to mitigate this effect. For example, drawing from the article, there could be tiered access control, where one tier (eg, 2fa but no pw) lets me get some limited access without changing the password. Then there would be no legitimate reason for returning to an old password, so such a policy is not harmful.
technion 9y ago
The policy of not allowing previous passwords exists in the first place to ensure password rotations really happen. I've been in organisations where you tell people that passwords change every thirty days, and they say "that's ok, I'll just change it and then change it back". Why do I need to change passwords every thirty days? Because it's one of only three questions our risk assessment auditors actually ask, and "failing" is bad news. If we accept we don't need to rotate passwords arbitrarily, there's no reason to have rules like this - it's more secure and less effort to not retain the last 20 passwords.

dustinmoris 9y ago

One thing which I find Troy constantly misses to advertise and which I personally think is a much better solution than using password managers and each individual system having to develop their own login + verification and security system is to use 3rd parties to authenticate. I am a big fan of password managers, but I don't think there is a need for them, because WE ALREADY HAVE ALL OUR EGGS IN ONE BASKET: email. If someone gets access to your email address then they have effectively access to every single service you signed up with that email. Therefore every single service might as well just use Google/Hotmail/Microsoft/etc. to authenticate their users instead of building their own login system and asking people to come up with a new password which forces them effectively to use a password manager and yet another place to store all eggs in one basket. The password to your email account == the password to your password manager. If we would all just rely on Google/Hotmail/Microsoft/Facebook logins then we would be even more secure then everyone having to use a password manager, and it would be a much better user experience. Also I am pretty sure that Google + Microsoft + Facebook have a lot more talent + resources to secure their accounts then every new service which pops up every day. Let them do the security and you focus on your actual business value...

CM30 9y ago
This has numerous problems though: 1. Not everyone uses those email services. Indeed, for a certain subset of users (especially on technical forums like Hacker News), using them is seen as opening yourself up to unwanted surveillance. This means tech forums relying on such a system are potentially driving away a decent portion of their userbase. 2. Not everyone wants to use the same account details. For instance, if I join a site with a more professional audience, my current username (and my email one) may come across as awkward or robotic. If I join a fan forum, I might want a username based on the game or show. Etc. 3. A lot of people want to keep their online identities seperate for security reasons. I mean, do you really want to use the same email for a dating site as you do your bank? Not really, but tying the login systems of each site to Gmail or the likes means you've either compromised said privacy or given yourself another Gmail/Hotmail account to memorise the details for. 4. It encourages centralisation. We've already got a problem with a few large services having an untoward amount of influence online, and having their login systems used for numerous other sites only makes that worse. It means if they decide your site is against the rules or 'hate speech', your users can't log in. So nah, I'd rather sites didn't use third party authentication. It has too many drawbacks.