I like the idea of a scheme that I can use with a preferred utility, but which I could assemble from commonly available tools if necessary. It's not too hard to find PBKDF2 in a Python or JavaScript library, or reimplement it yourself using even more commonly available primitives.
To be clear, I was never under the illusion that a password generator is as secure as a vault full of random passwords. The point is to improve on password reuse, or trivial transformations on a core password. If you generate random passwords for every single account, this is not for you, but it's probably better than storing weak passwords in a vault.
The problem, even if you ignore the straw men that usually get pummeled on threads like this, is that as you address the practical and security limitations of a naive scheme, you tend to lose the simplicity of the initial idea. You end up adding counters and password rules, so you have state to maintain/sync. Even if you don't treat it as secret, it chips away at the essential appeal of the concept. One comment on this post even mentions using a key file.
- Setting the master password to something insecure will undermine the security of all derived passwords. The same thing can be said for traditional password managers but they at least do not correlate the master password to all other service passwords.
- Master key is related to the generated passwords. Using a strong PBKDF this should not be a problem, but why take the risk?
- Leaked passwords cannot be changed.
- There are enough services which generate you a password and then only later lets you change it.
- Cannot store PIN, ID, CVV, files etc.
I can't remember what the crisis was but it was after Ashley Madison and there had been a series of password databases put up on tor. And also there were some things about people getting harassed across platforms. It happened right before I moved to a new state and when I set up all my new utilities and banking and etc I used a password manager and created unique username flavors. Like fluidcruft253b for water and fluidcruftAdaG for gas and fluidcruft563d for banking etc.
Interesting idea, but that seems like overkill to me.
Like, yeah, if I was to sign up for Ashley Madison, it would be ideal for me to use an email that is not my known one. ;) But in most cases I don't think that's adding much extra security. If anything, you're more likely to lose access to a site by forgetting what your super secret email for it was than from someone hacking it.
This isn't to say that I'm totally against it. Part of me just feels like there's more that can go wrong doing it that way.
1. If whichever identifier is used for login (eg. email address) is exposed/leaked, it cannot be used by the attacker to lookup accounts in other leak dumps.
2. It allows to detect which site/service/entity is selling or leaking email addresses to third parties which send spam. I no longer need or have a spam folder. The moment I receive a spam email from someone I don't recognize, I can lookup which site/service that email was for, and choose how to act; eg. update that site/service's to use a new email address and blackhole the old one; maybe unsubscribe/close the offending account if it happens again. Of course since setting up my unique-email-per-site setup, I haven't been victim to third-party spam yet; likely because I no longer have a personal email in public Github commits.
With a full-featured password manager it's only a matter of backups and remembering your master password. You don't worry about forgetting anything after that's covered.
I think there were also a bunch of social engineering things going on at the time. Things like calling up support and not knowing the password but combining info from different sites and username and email were enough to talk support into doing dumb things. Some of the dumps include things like "First pet's name" and all the common insecurity questions.
This is quite a big issue because it can be used for targeted attacks. There is no way of detecting compromises without reading the source on every page load.
First of all, this is not a transfer of trust from A to B: in both cases (traditional password manager or this thing) you still need to trust that your own device is not compromised. But with this thing, you _also_ need to trust that the website is not compromised.
Secondly, the website is a much juicier attack target than your personal computer.
Leaked passwords can be changed for this they have what looks like a version input. If the master key can be reversed from a cryptographic hash function either the hash function has been broken or you chose a really bad master key.
Although storing PINs and all the other random things some sites may use is a valid point. I am not sure I would call this less secure than a traditional password manager though.
> Setting the master password to something insecure will undermine the security of all derived passwords
Then don't do that. The question is: Is LessPass in practice more likely to encourage this kind of poor security than its alternatives?
> Master key is related to the generated passwords. Using a strong PBKDF this should not be a problem, but why take the risk?
If its PBKDF is broken then so is its security. If crypto is incorrectly implemented in any other password manager then it too is broken. If the crypto algorithms used by TLS are broken then our online banking is broken. We don't avoid other things that rely on crypto just in case they might get broken some day.
[Mods: accidentally posted this as a top-level reply rather than a reply to this comment, sorry!]
What's funny is I nearly just finished making a Node.js library that does what Lesspass does, and it addresses this one point.
Basically, I added a concept of an `nonce` property, which is just a number that gets incremented every time a password for a service has to change. (not sure if nonce is the correct term)
I figure that if I forget a password, I can just keep adding 1 to the nonce until it generates the current password.
Here's a gist of it: https://gist.github.com/Ravenstine/8053651dd2aeacee9973b9f93...
I haven't used it anywhere, so if there's a serious flaw don't believe you're going to access my bank account. lol
EDIT: It looks like Lesspass also uses a counter property. Kinda amazed that two people independently arrived at such a similar idea. :)
So your solution to issues with stateless password managers is to... add state?
Even Lesspass uses an incremented number for that purpose, from what I can tell. So it adds state in the sense that you're talking about.
The system I made "sinkless" https://github.com/kybernetikos/sinkless does the same thing. Its a pretty obvious solution to the problem of needing to able to change passwords, and it also solves situations where sites have crazy extra restrictions that can't be reduced to just the alphabet. My system also shows you emojis so you know when you've got your password and site settings right.
Most of the other complaints are also over blown, but the lack of 2fa is a genuine loss.
Another similar idea to stop people using the "just add a character or increment a number" method for dealing with passwords that need to be changed monthly. The password is based upon a hash of master+site+year+month+salt. You are still compromised if the master password is compromised, it is never any worse than what people do already. Again I'd not use this sort of thing for truly important accounts.
> Kinda amazed that two people independently arrived at such a similar idea. :)
I've seen many similar schemes, some identical to those I've considered and either dismissed of not found time to think through, some with minor variations. I think this is a problem a lot of people encounter so it is a common though-game, so I'm not surprised that for every combination of tricks there are a number of people who have thought the same (or even got around to implementing something).
The counters in lesspass, can be used to derive another password for the same website, if one want to change the password for the website.
HD wallet also has the similar functionality. If you want to change the bitcoin address, just derive another account from the seed password.
And the solution to keep the seed password of HD wallet safe can also work with lesspass. such as [OpenSK][1].
What do you mean? Does this tool prevent you from setting up 2FA on a service?
> and less convenient (changing a master password is a pain)
Changing passwords on many servieces is always as pain. But why should you change the masterpassword?
> than a password manager is getting so much attention (2000+ stars on Github, WTF!?).
Because it's pracmatic and secure enough. It's not secure enough if you are aome high value-target, but surprise, most people are just casual, which random malware and hackers being the worst level of attackers. Against thse this is plentiful, and better than what people use otherwise.
You don';t need to strive for perfection, when a 90%-solution works fast enough.
No I mean the password manager itself has no 2FA. It is impossible to implement 2FA on this kind of password manager. Almost all password managers like 1Password, Bitwarden, etc. implement 2FA so even if your master password is compromised (e.g. by a remote keylogger), an attacker can't get into your vault without physical access to one of your existing devices.
What makes you think that?
Because when a seed password is compromised it could mean all future accounts are compromised. So then you have to increment or supplement with some state, and change all past account passwords.
If a traditional master password is exposed its database/file may not have been. In that case only the master secret needs to change.
Edit: correction: seed not derived.
Uhm, no? There seems to be no direct relation between each passwords. So an attacker does not know by default that there is a masterpassword or what it is. For the real word there is no compromising if just login-data are randomly leaked.
A high level attacker who get's to know your used system could use it probably as an attack-vector, but again, that's not what normal people prepare for.
On a similar note, I also think it's bad security hygiene to have accounts on hundreds of services in the first place, if changing all of your passwords is an insurmountable task. Might I suggest deleting a few accounts a day for lent?
I don't understand this. In what case would there ever be "past" account passwords that I would have to change?
I use a traditional password manager. If an attacker, perhaps with a hidden camera, managed to see me type my master password, then they would still need access to one of my devices before they can use it. And if I had any idea that my master password might be compromised, I would change it just in case. It's quick and easy.
With deterministically generated passwords, all of my passwords would be compromised the moment my master password is compromised. I might not even _have_ a complete list of all the passwords that I should now remember to change. And I wouldn't do it lightly, because it's far from quick and easy.
Also, if a single generated password leaks, then an attacker could use that to start brute-forcing my master password. It's nice and all that there is PBKDF2 to slow it down, but the situation is still worse than with a traditional password manager, where one leaked password doesn't reveal any information about the other passwords.
On the other hand, if convenience is important, then I see no obvious difference between an online password manager and the OP's solution. In both cases, the security of your password vault depends directly on the security of your master password.
Encryption is a reversible process if you have the key. If you don't then it is effectively irreversible. It's definitely secure enough that we've built the entire internet and banking systems around it, so it's probably secure enough for your HN password.
Yes, but in those scenarios we use keys that are truly random. Deriving a symmetric key from a password and encrypting another password with it is simply never going to be as secure. You're better off storing it locally.
For physical access (like logging into a PC w/ SSH disabled), you only need 4 words to have sufficient entropy. Use 7 words if you want to reach a level of entropy that would literally cost decades of computing power to bruteforce.
That said, the 7 word passphrase should be generated by a computer anyways.
Also wanted to point out that the phrase "encryption is a reversible process" is hilarious. Encryption is literally about making it _as difficult as possible_ to reverse its process. Bruteforcing is not reversing the process.
And this is one of them. Because what particularly annoys me about this whole thing is that there already are perfectly good and well-supported authentication protocols, like SRP [1], that don't involve you sending your password to anyone. If we all just used that, password reuse wouldn't be something to worry about in the first place. Sadly, a lot of people saw it as trying to be a replacement for HTTPS (it is not), so it never really caught on, which is a pity IMO. The client side could be a built-in module in browsers or something like that.
[1] https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...
SRP isn't a perfectly good and well-supported protocol. It was made back when all sites used HTTP, and has taken years to finally get to a revision that isn't broken. You'd just be adding unnecessary complexity for authentication, when it's completely secure to send your password over HTTPS. And if the database was compromised, the attacker can still bruteforce the password verifier to impersonate the user. Yes, it's good that they won't be able to derive the actual password, but that shouldn't be an issue if people didn't reuse passwords in the first place.
At the end of the day, you're still using encryption if authentication is involved.
It's simply a lot more complexity for essentially no benefit. You now need to trust both the code on the server _and_ on the client to do the steps properly. Sending a password over HTTPS and hashing it is much easier for a developer to implement. There's definitely room for the password to accidentally be logged, but the same applies to SRP's password verifier, or the client's secret key, et cetera.
And if this is in the browser, then there's the issue of figuring out where to get an adequate amount of entropy on the client when generating the private key, or finding a polyfill to ensure keys are generated properly across browsers, or making sure you sandbox the code so that any third-party scripts can't access it. The general consensus is to avoid doing any crypto in the browser. These are just a few of the many reasons why people don't hash passwords on the client-side before sending them to the server.
About browsers: The default CSPRNG on Win10 and Linux don't need a constant stream of entropy to generate strong random numbers. But just for good measure, both of them incorporate mouse movement [1] [2], among other things. Your other comments assume the client code is in the JS, which I agree is a horrible idea (tangentially related: [3]). That's why I said it should be built into the browser directly (a pipe dream, but still). Though on a second (and rather perverse) thought, even if it's in the website, it will not provide worse security than sending the password... Nothing can provide worse security than that unless you downright "mutilate" the entropy of the credentials. Assuming everything happens over HTTPS, of course. Still, not something I would be proud to publish on github :)
About complexity: Good choice of words; password hash verification is EASIER to do than ZKPP. Not simpler. If you need to supplement it with an online password manager, or very good recall, or 2FA to ensure basic security, that's just pushing complexity onto the user. But I understand how you might see that as an unfair comparison, given that all of these things can benefit ZKPP as well. Just not as important - assuming the client side is properly implemented and the user chooses and handles the password with care.
Oh, and SRP doesn't define its "own" hash function. I've never heard of a protocol that does. Such things should always be configurable and left to the security architect's decision.
[2] https://pthree.org/2014/07/21/the-linux-random-number-genera...
[3] https://security.stackexchange.com/questions/214784/can-ads-...
At the end of the day, I'd much rather advise developers to hash & salt than hope that they can properly implement the 7 or 8 step process of SRP. That's an insane amount of complexity for authentication, with plenty of room for mistakes to be made. Developers have enough trouble getting even OAuth to work.
SRP gives you the same amount of security (arguably less, if the user chooses a weak password and/or the client code doesn't properly stretch the keys) as the conventional hash & salt.
You are looking at this problem based on what practices we currently have in place. Entering a password into an HTML form is NOT SECURE, period. It will never be. That practice needs to change first. Browsers already have built-in authentication prompts, for this exact purpose. But they're ugly, so no one uses them. Tough. To secure the client, one would need a browser extension that gives you a similar and distinct prompt with all the client-side logic in it. While this still leaves room for phishing, it is not enough in itself; you have to combine it with brute force. That alone is a huge improvement. It's not the "same amount of security". It would be lightyears ahead of what we do right now.
Now, what SRP does is prevent the server from mishandling the password. That means the server has no way of checking whether your password is strong enough. And why would you want it to? That's precisely the kind of mentality I wish just went away. Don't rely on someone else's computer for your own security.
I'm sure SRP has its own shortcomings, and some implementations are probably still buggy to this day. But that doesn't make hash verification one bit less horrible. Being reducible to a salted hash is about the worst failure mode there is for a ZKPP/PAKE implementation, so even if you make a mistake you're not worse off than what you started with. Also, two PAKE solutions seemingly more well designed than SRP have been published recently, SPAKE2+ and OPAQUE. I'm still trying to understand them, but I really like that OPAQUE's verifier is derived with symmetric encryption keyed with the registration key on the server side (as opposed to SRP, where it is a discrete logarithm puzzle), and if I'm not mistaken that takes care of quantum-resistance of the stored state as well (which understandably was not much of a concern back when SRP was designed).
What I meant by needing the user to enter a password (whether in a web app or native app) is that the user will still need to use a password manager and 2FA for decent security in the case that their password is compromised elsewhere. And no, you don't have to combine it with bruteforce if someone knows the password you use on an app that utilizes SRP. So it's not lightyears from what we have now. If you have the password, you can log in, whether the server uses OPAQUE or simply checks the hash.
A browser extension is still insecure third-party JS code. I honestly think there's no way to securely implement it for browsers, but it'd work well in native apps.
> Don't rely on someone else's computer for your own security.
Precisely. Use a password manager and assume the server is going to be compromised one day. Assume you might be phished one day, so you shouldn't use the same password for everything. That's the right mindset.
A salted hash is what all ZKPP implementations end up with. You can still figure out the user's password by bruteforcing the password verifier, because it's the hashed result of the ZKP's algorithm. My case in point is that you're achieving the same level of security as HTTPS + salted hash except in 7+ steps, each step leaving room for improper implementation.
Conversely, if an attacker obtains part of a server log from example.com, and my password is in there, they can impersonate me on example.com. It doesn't help that they can't impersonate me elsewhere because I don't reuse passwords. The damage is already done. That's because I trusted example.com to handle my credentials securely, and they didn't. I, as the user, had zero say about how secure the authentication process should be.
While I wholeheartedly agree that using different passwords, having 2FA enabled etc. is always better than not doing so, what I don't like is that these additions came about as artifacts of the crappy way we handle authentication. I want them to be a nice-to-have, an extra line of defense, not forced solutions born out of necessity.
And so, users shouldn't trust websites. That's why the browser is sandboxed. They shouldn't trust proprietary apps either, but now Mac/Windows users are accustomed to letting apps elevate their privileges upon installation. Assume they won't handle your credentials securely, and you'll be better off when security does inevitably break somewhere down the line.
You're wanting an ideal world where every service everywhere is using some sort of ZKPP for authentication, both the client and server are open source with reproducible builds, have security audits, and their users don't reuse passwords. I would love this too, but it's not reasonable. There's a huge educational and governmental gap for society to get there.
We'll always need password managers and 2FA; globally-enforced ZKPP's still won't stop that. Perhaps there's a use-case for them elsewhere that will be revolutionary, like end-to-end encryption with messaging apps. But for authentication? Just send it over HTTPS.
Honestly, I don't think this would require such a big change/re-education, but it's hard to tell. Historically, much bigger changes in IT security were implemented with success - like the widespread use of SSL/TLS itself, even though that consists of more than 7 steps as well, and aims to achieve basically the same thing as PAKE, minus the client auth being obligatory (or that can be a plus, depending on how you view it). Instead of an ideal world, I'd say 'alternative'. Hmm. So maybe SRP was all about succeeding HTTP after all...
That said, I wouldn't mind at all if a PAKE initiative started small, with a handful of websites. If they knew what they were doing, of course. That alone wouldn't eliminate the need for password managers and the like, but at least one less password I'd need to regularly check on HaveIBeenPwned. (Okay, that's a lie. I'm never checking them anyway. All talk and no action.)
ZKPP's
Pros
- You can make sure the server won't mishandle the password.
- You can let the client do the hashing, which helps alleviate server strain. You can set the number of hash iterations to a much higher amount than you'd typical use on a server.
- You've got a secure connection for client/server communication now; this in particular can likely find a revolutionary use-case, perhaps in gaming.
Cons
- Your developers have to learn how to go through the 7+ steps properly, until frameworks for it crop up.
- Less battle-tested: there may be more bugs and exploits in whichever protocol you choose due to how many less eyes are on it.
- Developers may choose a really weak hashing algorithm.
It would be pretty sweet for browsers to have one of the ZKPP's built-in, where the javascript can't touch the user's password or the code for generating the keys & initiating the handshake.
I think this is an exciting field of research - if in practice little more than a curiosity at this time -, and I expect great results to come out of it in the near future.
I need it almost daily. Being a developer and almost always in a terminal it’s convenient to retrieve a password really quick when needed.
This is only slightly better than the brain wallet concept for personal key management and back then people thought it was a good idea too. So I guess this kind of attempts will never go away.
This is the exact same problem with brain wallets, for which people delude themselves into thinking that they have managed to conjure a secret phrase that only they will know, only to get hacked in no time because the passphrase they came up with was just bad and they could not tell.
That’s heavily misleading, like complaining encryption is performed using a key partially known to the attacker because a nonce/IV is involved. The site name and username are there to derive different keys, not provide security.
Let's pause for a second and think what is the point of using password managers - I take it as a means to allow each account to have unique passwords that the leak of any of them won't lead to more account breaches. The method being shown here does nothing in this aspect as every password is effectively the same master password hashed with a known salt. One might argue that a costly derivation path could make bruteforcing impractical but it doesn't help with the fact that the concept is unsound from the beginning.