I honestly am baffled how such a bad idea which is objectively less secure (no 2FA) and less convenient (changing a master password is a pain) than a password manager is getting so much attention (2000+ stars on Github, WTF!?).
As someone who looked seriously at a scheme like this before reluctantly using a password manager instead, part of the appeal comes from vault anxiety. If I don't have the vault and a tool to use it, I can't access my accounts.
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.
We've seen many of these tools and they are all flawed in the same way.
- 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.
Also it requires you to remember usernames or email addresses used at each website. For the last 8+ years I've been using unique usernames and emails at each website. I also have to deal with a number of systems that require me to change passwords every 3 months and I don't want to also be remembering dates.
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.
> Also it requires you to remember usernames or email addresses used at each website. For the last 8+ years I've been using unique usernames and emails at each website. I also have to deal with a number of systems that require me to change passwords every 3 months and I don't want to also be remembering dates.
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.
Those of us using a different random username and/or email address for each sender do it for two reasons:
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.
> 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.
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.
- LessPass is a webpage that can be changed at any time and collect website, username and password triplets.
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.
If you choose a strong master key this should still be secure even if a site leaks a generated sub-key/password. All you need to do is change the sub-key for that site. Both this and password managers though still can be hosed if the machine your using is compromised. Otherwise it should be secure as your master key.
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.
You make some reasonable points, but two I find somewhat strange:
> 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.
In a sense, but not state that gets stored anywhere. The "state" that's being mentioned in this thread is referring to storing state in some kind of database. My idea was to not require storage of state outside of the human mind, and to make any state easily guessable(by the owner) through exhaustive search.
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.
> It looks like Lesspass also uses a counter property. Kinda amazed that two people independently arrived at such a similar idea. :)
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.
I had a similar intent for less important accounts (I would keep using a more secure but less convenient solution for more significant credentials). To shortcut guessing the index you could store just the site plus index in a cookie or similar - if that data is lost you can still use the guesswork option. If tracking is a concern so you don't want site names to be stored, has the site name and index and use that to build a bloom filter (not perfect, but it will usually guess right without storing the actual data). Though for my use I wouldn't care that the site names were known.
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).
Because it solves real problems (it's very easy to use, and I use a lot).
It works similar with HD wallet in bitcoin or ethereum.
In HD wallet, you can derive accounts for many crypto currencies from one seed password which is what master password in lesspass does.
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.
> What do you mean? Does this tool prevent you from setting up 2FA on a service?
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.
> Changing passwords on many servieces is always as pain. But why should you change the masterpassword?
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.
> 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.
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.
It seems like Lesspass would be encouraging best practices in that case; if you believe your seed password has been compromised, then you _should_ change all of your passwords.
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 agree that it's worse, but I'm not that surprised about the attention. I've seen people come up with this idea in multiple threads about password managers, so there is clearly something appealing about it. Instead of seeing the traditional "stateful" model of password managers as additional strengthening (like I see it), some people see it as a weakness that we should get rid of. I don't understand why. Under what threat model does it make anything better?
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.
I think online password managers are a bad enough idea already. You should never send your password to anyone (except to the service you're using of course). Not even in encrypted form, since encryption is a reversible process.
It's a vast improvement over the traditional alternative of people reusing passwords across sites IMHO. It's hard enough to get non-technical people to use passwords managers. The chance of getting people to use a password manager without a usable syncing capability is virtually none.
It is an improvement, for sure. And probably good enough for the average user.
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.
I don't think that assumption is true because it should be far more easier to brute force the master password of a deterministic password manager. Worse, the OP's solution accepts "password" as a master password, which means that many, many people are going to have the same generated passwords if this gets widely adopted.
That's... not reassuring. Though I would still argue that that is more of an implementation issue, not a deal-breaker for the general idea. And there are many KDF variants that (claim to) offer protection against brute force, so that's not necessarily an issue either (but I do agree it sounds risky).
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.
"we've built the entire internet and banking systems around it"
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.
In fact, some password managers (well, at least 1Password) do generate a random secret key that you're required to provide at login in addition to your master password.
You need an already logged-in device or a printout of the secret key to login. The former isn't much of a concern because if an attacker has access to a logged-in device, you're screwed anyways. The latter would require physical access to your home, and the same applies here too.
Encrypted communication relies on keys generated by computers. They have significantly more bits of entropy than a master password produced by a human.
The major problem with passwords is reuse. Nobody's out there trying to bruteforce your passwords, unless you're a state-level threat. In reality, they'll be using your password from a database leak from a different service and programmatically try a few variants of it before moving on to the next target.
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.
I don't think encryption being reversible is anything to be laughed at. This leads to a lot of other caveats. For example, the length of the plaintext is in correlation with the length of the ciphertext. From this, an attacker could potentially tell if a managed password is short enough to be even worth trying to brute-force. And yes, passwords could be padded, yes, I'm oversimplifying things here, but my point is, in some cases encryption is not the best tool.
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.
PBKDF2 solves all of those issues, which LessPass uses. I think I understand what you're trying to say, though; it _is_ insecure to rely on the user for entropy. If the master password is weak, that consequently weakens the entropy of the generated passwords. PBKDF2 does a lot to add entropy to offset this issue. From there, you can generate passwords of any desired length using the entropy of this PBKDF2 key. And brute-forcing these generated passwords won't tell you anything about your master password.
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.
Small correction: an attacker needs a password verifier AND the server private key to brute-force an SRP password. Also, I think it's great that there are no known attacks other than brute force - even if it took several iterations to get there. As you said, the more realistic failure modes are data leaks, like passwords getting into the log files, or getting hashed without a salt, or not getting hashed at all. All of which are covered by SRP by design.
Sure, but if the database is compromised, the attacker will have the server's private key. They can still bruteforce passwords, except against SRP's less battle-tested hashing algorithm.
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.
I mean, leaking an SRP verifier into the logs is analogous to leaking a salted password hash. (Same story if a client key is leaked, since replay attacks are not possible.) That is still 1000x better than a plaintext password leak. Which happens... how often again? All it takes is one oversight by one developer and one rushed code review. Addressing arguably the most common way passwords are stolen nowadays is not what I would summarize as "essentially no benefit". And no, you don't have to trust the server to get that protection. Your password never leaves you, that's the point. An entire class of attack vectors just doesn't exist here. Including phishing attacks - if the browser gives the user unambiguous visual clue that the auth is happening through SRP.
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.
Yes, verifying the hash of a password is simpler than SRP. You'll still need a password manager and 2FA with SRP. The user will still be entering in their password into a form-field on the client. You'll still need 2FA to make sure it isn't a credential stuffing attack, or someone who phished them. And yes, you can still be phished with SRP. SRP doesn't mean there is no password. You'll still want a different password for every service.
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.
"The user will still be entering in their password into a form-field on the client."
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).
> Entering a password into an HTML form is NOT SECURE, period.
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.
Compromised where elsewhere? I control my password, so I know exactly where it goes and doesn't go. And the only place it ever goes is the little green box in my zero knowledge password extension (or native app if you prefer). I, as the user, have complete control over my own security. If my password was compromised in any way other than brute force, I can be 100% sure it was my own fault. Maybe I didn't inspect the source code well enough, maybe I talk in my sleep, but it's all on me. Saying that someone can obtain my ZKPP password through a different channel is just as nonsensical as saying that someone could get their hands on my password manager's master password if I once made an account on a pizzeria's site with the same credentials. Well, I shouldn't have.
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.
Perhaps you have a keylogger on your computer. Or a malicious app was able to access your clipboard. Or a third-party script on the site hijacked the form submission (Magecart, which is still an issue to this day). Or perhaps you're using a native app that isn't open-source, and they send your credentials to their servers to create their own list of passwords for credential stuffing elsewhere. There are many possible channels to be compromised. Sure, these are "user errors," but people have to use proprietary apps and websites for their day-to-day life. And people still get phished.
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.
If I had a keylogger or other spyware, even my password manager's master password wouldn't be safe, so that line of reasoning still doesn't sound convincing to me. :) Only 2FA could prevent that, and I don't mind using 2FA as much as using password managers because it actually brings in something of value, something other than a "what you know".
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.)
You know, I'm almost sold on it. I still think it's a bad idea to use it in the browser, but for native apps/games, some of the pros could be really nice (particularly client-side hashing).
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.
Glad I could get you a bit more interested in this kind of approach. Your summary makes sense to me, though admittedly it is damn hard to reason about the security of these things correctly. Getting the client to do the hard work really is an added bonus, now that you mention.
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 built this to allow me to manage my passwords on my machine without sending them to any third party. The data lives on your machine encrypted with a master password, but the encrypted data never has to leave your machine or network: https://github.com/whatl3y/hide
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.
Cryptography is hard, opsec much harder. I frowned immediately when I realised that it generates deterministic password from seeds partially known to the attacker.
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.
If part of the seed has sufficient entropy, it doesn't matter if the attacker knows (or can guess) another part of the seed. Assuming the software uses a decent cryptographic hash function properly.
This is true, however I can't help but feel that the design of the system encourages users to choose a low entropy master password and get a false sense of security seeing a different "strong" password can be produced for every account. The fact that the master password has to be typed frequently to recover the derived passwords adds to the problem.
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.
Except in this case there are no IV or nonce involved and every key derivation is perfectly replayable.
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.
salt = (
password_profile["site"]
+ password_profile["login"]
+ hex(password_profile["counter"])[2:]
)
It’s not ideal for “myusername” on “example.co”, “yusername” on “example.com”, and “yusernam” on “example.com” with counter 225 to produce the same password. Maybe it never affects anyone, but it’s so easily avoided there’s no reason to make this a hazard.
`_insert_string_pseudo_randomly` seems overcomplicated compared to just putting `string` at the end, too.
I don't know, but syncing was never a problem for by tools. Use bitwarden, lastpass or some other available, good working tools and don't waste your time like that
I'm also a fan of Bitwarden. It's e2e encrypted, so they never get to see yr password. The Browser plugins are opensource and an open source server impl exists (but since it's e2e is not essential for security).
While this is nice in theory, it lacks the following I use: usernames, TOTP, credit cards, attachments (like scanned 2FA number grid some banks use), history, autofill. And how does changing master password works?
TOTP should NOT be stored with your passwords. I know some password managers give this option for convenience but the point of TOTP is it’s something you have (traditionally a physical device) that’s separate from something you know (a password). When both of those things are stored on the same place then it effectively just becomes multiple inputs for 1FA.
This just means the poster above doesn't consider a compromise of their password manager a risk. It remains 2FA because the key material for the OTP does not leave the password manager, whereas the password travels down the wire. For a start, this makes it hard to brute force the account for even an inept provider.
I also have 2 db (KeepassXC), I have my low security db (like games, online stores, forums...) and my high security db (like AWS credentials...), the second one requires a hardware key for unlocking.
But some websites (like some games) in the first category have mandatory 2FA.
The biggest reason to keep TOTP in a password manager is that people are more likely to use it, which is a much better security stance than having a better system that no one wants to use.
For example, if you use 1Password to fill in your creds on a website with a stored OTP setting, 1Password puts your OTP on the clipboard so that you can just paste it into the next page without taking any other steps. This has driven up adoption immensely at my work.
a much easier way to not have to remember a password is to reset your password every time using the 'forgot password' feature available for most sites.
You generate a new, random password for that, but you don't remember, nor store it. You just use the forgot-password feature next time you login.
This way, you just need to secure your email provider's password (say, gmail is pretty good - 2-factor and they constantly check for weird logins).
> Most sites these days ask Security questions and it is no longer a single click from email.
yes, i noticed. especially apple itunes/icloud. I hate them. And i consciously choose to avoid sites like these.
I prefer sites that mail you a one time token to reset your password (and also log you in automatically). Or you can just copy the password once, and do the login for that one session.
My answers to security questions also use a stateless security question answering script.
The reality is most security questions are horrible security questions (e.g. what is your pet's name -- for people with pets that's usually referred to multiple times on Facebook statuses)
The service I work from doesn't use passwords to log in at all, it just sends a confirmation mail to your inbox.
Given that password resets exist everywhere, your security is already 100% bound to the security of your inbox, so you might as well cut out the middle step.
In a previous gig I worked on an identity system for a large media company. Using the forgot password link on every login is actually a very common pattern - though I think the reasons most people do it (they log in and are rarely logged out therefore they just forget the password) are different than your reasons.
I wonder if that's the reason why google makes it nearly impossible to recover your password through forgot my password button. It's pretty useless now.
weird, how everybody has a negative sentiment, but also doesn't consider not using the fields as the labels indicate... and ALSO thinks this 8s an "online" thingy for some reason...(it just has a javascript version, just like it has a python version)
you don't need a full username or email at the "user" field, can just use gmail@alice or JohnDoe-bank.com and whatnot, similarly with the "site" field...
can also cut them all off, say, skip the first, or last character...
you don't need the same master password... but more than that, you don't need to start at counter ONE...
you might start at counter len(domain) or len(name), for example...
IF you have 1000+ passwords, by all means, use a traditional manager... but this is perfect for people with less passwords, no sync needed if you don't want to, your passwords file cannot get lost or stolen, etc...
This is such a bad idea. Now you have to remember the counter field and username you used for each site. Also you can’t change your master password without changing every single item in your vault. As a person with 1000+ passwords, this would never work.
And the fact that your passwords are deterministic means that somebody who has one of your passwords can learn the master from it and pwn you everywhere.
Some non-secure login forms do still exist. Boardgamecore is one of them (shame away, the webmaster seems to think it's too expensive to get a cert and I can't talk sense into him). The whole internet knows my boardgamecore password.
I don't care too much though, because I use LastPass and that password is random. The worst you can do with it is make a bad move in my chess game. The fact that my board game password is public doesn't endanger any of my other security. My master password is still entirely out of reach.
But if I was using LessPass, you could use rapid offline cracking to derive my master password from my boardgamecore password. If you get lucky or if my master isn't strong enough, in short order you have my email and my bank and hundreds of other things, which I have to go change manually one by one after I figure out how to deal with the fact that all my money's gone.
With a deterministic password system, if somebody pwns you somewhere, they've pwnd you everywhere. It is only mildly better than reusing the same password everywhere. The danger of so many points of failure and no failsafety is definitely not worth the theoretical purity of "statelessness" (which you don't even really have because the state is in your head or a Google sheet)
Your bank allows you to move money with just a password? Change to some bank where you get a way of logging in that requires some sort of certs. Ours used to have a small box you had to enter a key that the website provided to you, plus your pincode. Now there is an app that displays where you are logging in and you have to enter your pin to sign. When you transfer money it needs another signature and you can see all the transactions on the same screen before you hit enter.
Actually all you need to move money is an account and routing number. In US banks, that's all you need for an ACH pull. No password, no pin, no nothing. Learned that the hard way when a friend accidentally stole $5000 from me because he thought my account number was his.
But presumably you can just unwind that? In the UK the "Direct Debit guarantee" paperwork that's included with every form where you give people your account details explains that the bank promises to unwind any transactions that you decide you didn't want.
Direct Debit also only works if you're an accredited recipient, because obviously under guarantee the bank is going to want to claw back that money it just refunded and so they need to know the recipient can afford that almost always. The huge global utility company won't go bankrupt if I unwind a monthly utility bill payment, but the fly-by-night vape shop might. Presumably ACH pull is the same?
> And the fact that your passwords are deterministic means that somebody who has one of your passwords can learn the master from it and pwn you everywhere.
Don’t use a trivial master password then… if you only need to remember one password, it may as well be one that can’t be cracked with a single fast hash, let alone PBKDF2x100000.
I use a stateless password manager with over 110 passwords. What I do is keep an Google Sheets document with the site, how it was generated (i.e. weird password rules), and a password version in case I ever need to change my master password. It has worked pretty well for me so far even when I have had to update passwords due to sites being comppromised/password update policies.
Changing master password is a pain in the ass which I did once since my original master wasn’t very strong but is doable. Plus, a master password should really be changed rarely IMO.
The benefit is that most of the time I don’t need to the Google Sheet since I can usually remember the key and it is more for passwords with weird rules or ones I don’t use often.
As for why stateless, it is much less work to get a new machine up and running. Plus, it is much friendlier at my current job since I can’t even send a word doc out to my personal email much less syncing a password vault. Much easier to have one stateless manager and separate spreadsheets for storing metadata.
well keepassxc has a portable version on Windows (and a similar appimage on linux) so if you can run it from a USB in your place of work then you wouldn't need to set anything up each time you use a new comptuer.
you could also download your keepass file from something like dropbox either, but that would be a bit more effort if you were creating new passwords in work since you would have to upload it again after
> Now you have to remember the counter field and username you used for each site.
No you don't. You can store it anywhere you like. It's publicly-safe information. The counter isn't a form of security; it's merely a vector to generate a new password from the master one. You could write the counter down on a piece of paper and show it to everyone and it wouldn't matter.
That's what I'm struggling to understand. They open by describing the magic that comes from just computing the passwords every time you need them. As they say, "It does not need to sync your devices". And then they explain that they had to build a "connected" version, because¸ as far as I can tell, their core approach doesn't work in practice.
I just keep a Google Sheets as a primary backup for the meta information. Plus, you just build in aggressive local caching for saving config options about sites.
I have a similar stateless password manager I wrote. I just store the counter in a JSON file along with other parameters, e.g. Baidu doesn't allow passwords >16 characters, usps.com doesn't allow symbols, some other sites require symbols, some require a number, some require a number but don't consider 0 to be a number, etc.
All of these things, including the counter, don't particularly need to be securely stored and can just be in a file in a git repo or Dropbox. Not needing to be securely stored eliminates many of the concerns with stateful password managers.
An encrypted password file, such as a 1password or keepass database file, also doesn't have to be stored securely and can just be stored in git or dropbox or whatever.
You're trusting crypto to not be broken either way, why not trust an encrypted file that provides significant usability rather than an unencrypted file and "stateless" generation algorithm?
Seemed like a good idea at first, but I can quickly think of many shortcomings:
I wouldn't know wtf my password is. And in case a login to one of my sites fails, I wouldn't be able to manually copy paste the password and go step by step?
What if the domain name of the site changed?
How is it supposed to work with mobile versions like m.Facebook.com?
Or how would it work with apps?
Is there a way to tell a login applies to multiple sites?
I'd be stuck in this stateless non-transparent world without knowing wtf is going on I guess. And not to mention I cannot maintain things like notes/cc info etc.
What I learned from this thread: even engineers use insecure vaults with repeatable, deterministic, and exploitable passwords.
Are there any non deterministic unique passwordless way to login without depending on any entity?
Can you use your blood or state of the body to login?
Each time you login, there will be some differences but not enough that you could not match similarity. It will adapt every time you login and forget about past states.
Over a long duration without logging in, your blood or state could be much different so there is no chance of forever having lost your login if something is compromised.
There’s the concept of unclonable physical functions (PUFs) (https://en.m.wikipedia.org/wiki/Physical_unclonable_function) that can provide something like this. Some companies like Physec offer key derivation mechanisms based on PUFs that depend on the physical characteristics of the environment of the device that generates the key (e.g. the electromagnetic impedance), so an attacker needs the actual device to produce a key that matches the profile, and tampering with the device by e.g. opening it destroys its ability to generate a key due to changes in impedance.
It’s a really neat concept but I don’t think anyone found a way to apply it to a human, though it should be possible (e.g. using your heartbeat).
> LessPass even stole the "one password to rule them all" ...
That phrase is a reference to Lord of the Rings, and an obvious one at that. Doubt passwordmaker was the first or last time someone comes up with that line.
That may be true. But this isn’t a great example of it. This is pretty much the most naive (not in a bad way) evolution of password management possible:
Q: I need passwords for all my accounts. What should I do?
A: Use the same master password everywhere.
Q: But if one service has a leak all my accounts are compromised
A: Then just combine the password with the url. Like password|url.
Q: Well that helps against automated approaches, but a human could pretty quickly deduce all my passwords.
A: Hash it.
Q: Cool. Now what about when I need to rotate a password for an account.
A: Add a version number and hash that too.
Q: Cool. Now what about when I have different accounts with the same url.
A: Just hash the account name too.
Q: Cool. What about some websites that have specific password requirements?
A: Uh. Map the hash to a language with the symbols you need and try to remember what that language was when you need the password again.
Not answered, but interesting to consider:
How can I avoid needing to remember the language? (Online service mapping domains to password requirements? But then what about then they change over time?)
How do I remember what version number I’m on? (Online public mapping from hash(username|url|userID) => number? But who has write access? Everybody... blockchain?!?? This could also solve above question. )
I'm using something kinda similar to this :)
Pre-programmed my YubiKeys with a 'master password' in a safe environment, and using their HMAC signing capability to generate consistent passwords, kinda similar to your algorithm. This makes sure the master password is safe, and that passwords can only be generated one at a time when I press the YubiKey. https://github.com/noliran/ykpass
Why can't people use keepass in local environment, or store the database in sftp? Why do people try so hard to use "cloud" based clearly unsecure solutions?
This reeks of the infamous dropbox comment on HN. Let alone the fact that the average user has no idea what SFTP is nor has any easy way to use it, even as a tech literate used who has no difficulty setting up the solution you describe, I would not switch from a more dedicated solution, because quite frankly it sucks. You have to manually sync, the sync cannot deal with two different systems adding different accounts, you now have two systems to deal with (sftp and keepass), and you're not significantly more secure. I would go back to reusing passwords before I adopted such a solution.
Keepass automatically syncs. Kypass (mobile) automatically syncs. All it takes is to enter sftp credentials to KeePass, and the rest is automatic. Not sure why you couldn't figure it out, but it works for the last 5+ years flawlessly. I didn't touch a single button to do anything extra, all I need is my SFTP credentials (once while setting up) and master password to open in my local machine.
As a Keepass(keepassxc on Ubuntu) user I recently switched to Strongbox from the now abandoned MiniKeePass, which I have been very happy with. It supports using FaceID with a Pin, which is great for quick access on my phone. Syncing with wireguard/resilio sync.
+1 for bitwarden, it's open-source (both client and server), and does the job well (only issue is the UI in the firefox extension can be a little frustrating).
2-) Sftp = not cloud, dedicated non-public server which you can also setup in your home environment such as a nas drive which only and only you have access to.
3-) I am convinced it is the safest, because no 3rd party is involved in my perfectly synced password system.
I have a setup with syncthing to transfer it between all my devices without going to devices I do not control. Previously I used Dropbox, which while putting your encrypted vault on a third party service, is easily accessible to non-techies
I have wireguard setup for my home network and phone. Then I use Resilio Sync to perform the synchronization between my phone and my home network once wireguard is connected. Allows me to synchronize from anywhere securely.
Assuming your master key/password is strong this system is still secure if one the sites you use leak the generated password. However, if you somehow leak your master key then all your accounts are exposed.
It's weakness mainly is if the machine you use is compromised so are your passwords. However, the same applies to a password manager. Unless you use an offline system to generate these sub-keys.
It's a bit of a cheat to argue this is stateless, given that the profiles (which stateful pieces of information which contain information about password complexity rules for each site, as well as which version of the password you're using) are synchronised with an online service. It is nice that you can self-host it though.
While I do applaud the idea (synchronising password databases manually is definitely something that gets on my nerves -- I use KeepassXC), I think the benefit of having completely random passwords that have no connection with each other is much higher. With systems like this, you have to have very strong confidence that your master password is very strong and will never be discovered. But with a file-based system, even if your master password is weak or compromised an attacker still needs to get an up-to-date version of your password file.
I'm also pretty sure I've seen this idea implemented a few times over the years (it's not clear to me if this is a new project or a reposting of an older project).
Wait, so if somebody learns my master password somehow, they automatically get access to every website I've registered in, without even needing to steal my database and such? Not sure that's a good idea.
I solved this problem in my deterministic password manager: passwords are generated from a keyfile, which is encrypted with your master password. This means that if someone gains access to your master password, they can't do anything without the keyfile, and likewise if someone gets access to the keyfile without the master password. Also, changing the master password becomes a simple operation (the keyfile is simply re-encrypted, no need to change site passwords). Since passwords are generated deterministically, the keyfile needs to be synced only once to all devices, after that you have syncless operation. https://github.com/baobabKoodaa/baopass
Encryption allows you to change the master password without forcing you to change all site passwords. To illustrate:
Scenario A: keyfile is encrypted with master password, site passwords are generated from plaintext keyfile. If the master password needs to be changed, the keyfile is simply encrypted again. The plaintext keyfile remains the same, which means all generated passwords remain the same. No need to change site passwords.
Scenario B: keyfile is not encrypted, both keyfile and master password are used as inputs to generate passwords. In this scenario, any change to the master password causes all generated passwords to change. This would obviously be undesirable.
The point is to decouple the master password from the generated passwords. The file can contain as much key material as you want, so it's stronger than any password you can remember.
Then I don't understand how you "combine the master key and keyfile data to create your key." How do you change the master password without changing the generated passwords?
It uses PBKDF2-HMAC-SHA256 on a master password concatenated with the domain of the service you need a password for.
*It only requires storing information about per-domain idiotic password requirements (min length, max length, require symbol, etc.) and the Nth password you use on the site.
I honestly wouldn't want to have to change my master password to change a specific password on a site. It's a neat idea but not one I'd use in practice.
It has a great command line interface, is simple to audit, levers gpg for encryption and git for synchronisation, and has browser extensions and apps for android etc too. It even has an extension for OTP.
I've even gone to the length of using it in scripts to inject secrets: "pass buildsecret" will yield the right string. With a thin wrapper that can be supplied to ansible, or terraform, or whatever. It's great. Plus, I can change passwords arbitrarily.
Pass is great, but it's a very niche piece of software. I was actually surprised (but grateful) that it existed because so many people have a GUI password manager.
I have the Firefox integration (and I contributed to that integration) and like that much better than other software I tried in this space, not least because I understand all the moving parts so if they break I'm not helpless.
I actually did use the Stanford PwdHash linked above on some systems precisely because password managers were so unsatisfactory. But it's clearly true that if any solution in that class were significantly popular it begins to make sense for bad guys to attack that specifically - assume the gibberish in stolen plaintext passwords is actually output from a "stateless" scheme like this and brute force it. Once you decide to compensate for that (e.g. maybe you're going to have a 12 random character master password entered every time you log in somewhere) password management seems like the less awful option.
I'd like to see low value sites that this sort of thing is clearly most suited for (so like Hacker News, or Stack Overflow, not your bank) offering WebAuthn with no password. Blip, you're in. Very safe, but also very low friction.
I made something similar back in 2018. Initially started as a bash script, later on added web version so I can use it from mobile devices.
It let you reduce the generated password length so it can satisfy the "security requirements" of some sites...
I suspect those sites are storing plain text password in a SQL table column, otherwise why would it limit the length to not excess 12 or 20 words?...
I shared it to some peers but they just prefer to use password they can remember by their brain ....
The counter for password change is a great idea! I was aware of this limitation of stateless password managers and I always looking for how they solve the change password problem. Nobody solved it so far, this is the first I saw. Good job!
All previous deterministic password managers could also be used with a counter: instead of inputting site "hackernews" you would input site "hackernews2" etc...
Jeez, I probably invented using Javascript to generate site passwords by hashing the domain with a master password (see e.g. https://books.google.com/books?id=4jYEAAAAMBAJ&pg=PA34) – and I certainly don't use it any more!
I used this (or a variation of this) for years. In the end, its inability to handle changed passwords was its downfall. If your bank doesn't let you use the specific password this generates because of some random stupid rule ("your password can't contain two numbers in a row"), you're out of luck, there's no way to generate a compliant password without remembering either a completely different master pass or that the counter for that site is now set to 2/3/whatever.
I also found that having one master password like that is probably not so clever. But who is saying that you have to use the three input fields like this? I came up with my own system.
So I'm kind of using lesspass now as a password generator. The generated password I save in keepassxc along with the rest of the information. In most cases I don't need to consult the vault and can generate the password on the fly but I'm not bound to lesspass at all. So in case I should lose access to the vault I can still log into most sites.
not it's not just a backup. I backup my vault of course.
it's:
1. a way to access most of my passwords from everywhere even when I don't have access to the vault
2. a way to access most of my passwords even when all of my vault copies and backups are destroyed
I like that it is deterministic, and I was going to ask what if a single password was compromised, but it looks like there is a "counter" field for each site that overcomes this. Nicely done.
I used to use a system like this for passwords. The downfall is it depends on the site name being exactly right. For instance a naive program will treat example.com and login.example.com as different sites with different passwords, which is a real problem in practice. You can work around this but ultimately it means the user has to keep some state in mind, which is "the real site name for this site that I used to generate the password". I was surprised what a pain that was back when I did this.
https://webpass.rkeene.org/ is also similar, but a single JavaScript file which you can host yourself. It also supports syncing, but for this it needs to reach out to a server. It doesn't store the data on the server, though, just passed it through to another online host.
This seems similar to how crypto wallets are often generated -- with a seed phrase. Exposing that master password regularly seems dangerous -- if it leaks once, you're screwed. Hence why crypto wallet seed phrases are (supposed to be) carefully secured offline.
Just so people know, if you have to change a pass with Lesspass, because a site/service got breached, you can simply increment the password up by one to get a new 'hash'
is it just me or is this just off-loading the same password use on many sites on to an algorithm. After all, your username is quasi-public info and the site can not even be called quasi. It is fully public. Few options will not make it unique enough that it can notbe broken. After all, the only thing that the nefarious person needs is your master password and knowing your mom/dad/grandma, it is written somewhere under the mouse pad or in a file on the computer call MyMasterPassword, waiting to be stolen.
Now the effective password (the secret shared between client and server to authenticate) is the hash. So you actually do still need to store the cleartext of this secret.
This might be fine, one of the built-in mechanisms of HTTP that we essentially never use works this way (Digest authentication) but it's far too late to agree it now (every client would need to agree to do this or else you need a complicated fallback plan) and it doesn't do much for you security-wise.
You could use an asymmetric PAKE and that gets you a few more benefits but again every client has to implement this so the back compatibility story is horrible.
Secure Remote Password (SRP) is a protocol for verifying a password without knowledge of the actual password. Now we only need all browsers and applications to support it! Well and a way for initial setup (sharing the seeds).
This has been thought about. Digest auth is a thing, but is stuck on MD5. However, with how flexible a web-form is there really is no way to enforce it so idea never really went that far.
I experimented with a similar idea, but with a solution that I think is simpler. My idea is called "Skipper": A dead-simple password keeper that is end-to-end encrypted, open-source, and free. A master password syncs your encrypted database store from any decentralized cloud hosting service. It's not fully featured yet, but others could add layers on top to add 2fa, proper federation/decentralization, etc.
With modern React, I can’t tell whether this is server-side, client-side, or potentially both. If it’s server-side, that’s ideal, because the way the server stops responding to all requests for several minutes will make you fix this before that Firebase query really starts costing (but still, why does this exist). If it’s client-side, are you really exposing every user’s hash to offline attack?
export function saveMasterPassword(masterPassword) {
const simpleCrypto = new SimpleCrypto(MASTER_PASS_SECRET);
const cookies = new Cookies();
const masterPass = simpleCrypto.encrypt(masterPassword);
cookies.set(COOKIE_MASTER_PASSWORD, masterPass, { path: '/' });
}
(uppercase values are server-side constants)
If you’re serving the same cookie encryption secret to everyone, is it really a secret?
function cypherObject(object) {
const cookies = new Cookies();
const masterPass = getMasterPassword();
var simpleCrypto = new SimpleCrypto(masterPass);
if (typeof object === 'object') {
const object = JSON.stringify(object);
}
return simpleCrypto.encrypt(object);
}
simple-crypto-js uses 100 rounds of PBKDF2 to derive an AES key from `masterPass` here, so your brute-force resistance to an attacker with access to the encrypted secrets comes from 100-round PBKDF2, not 2^10-round bcrypt.
You mean you've been making new, unpredictable passwords by tracking only the usernames and counters? You must be good at hashing ;) Seriously though: this is going to be relatively secure only if each counter increase gives you entirely random password.
The way a stateless password manager like this works is that it defines some function F(url, username, counter, settings, master_password) and F() returns some random string which is the password for the site. The settings include the characters to use (a-z, A-Z, 0-9, and symbols - each a boolean - so, 4 options for a total of 16 combinations; there is also a length parameter defaulting to 16 - but lets assume that users primarily use 8 - 20 for a total of 12 different values. This gives us a total of 12 * 16 = 192 total values for the settings field). The user is expected to remember the counter in some way - but the default is 1 and we can assume that most users have a counter value somewhere between 1 and 10. The function F() hashes all this stuff up in some sort of unchangeable way (changing it would modify every password and would thus render the whole thing useless) and produces the random password. Let's note: the url of the site and the username are both public information. As above, the settings field has ~192 possible values. And the counter has ~10 possible values. The only thing that has significant entropy is the master_password.
So, we have an equation that looks like: site_password = F(url, username, counter, settings, master_password). But, as above, we know url and username and there are only about 1,920 combinations that are likely for settings and counter.
Let's say you use this to generate a password for some site that stores the password in plain text. If an attacker gets that password, they now have the opportunity to brute for the master_password value. A GPU based attacked can attempt a very large number of passwords per second (hundreds of thousands to billions per second, depending on how F() works) in a fully offline manner - the only thing slowing them down is that each master password that they check has to be rechecked against each of the 1,920 combinations for settings and counter. This slowdown is extremely minor when the attacker can run a tremendous number of guesses for the master_password in parallel. The settings and counter field basically work as a salt - but unlike a real salt value that would generally be a 32 or 64 bit number, this salt is super tiny.
Anyway, a competent attacker will figure out how to brute force the master_password without too much effort. And the big problem is that that master_password can then be used directly to calculate the site_password for every other site that you log into. A couple reasonable guesses about what counter you used and what settings you likely used for your bank (likely the defaults) and the attacker is in.
The combination of settings and counter provide no real security. If a password is stolen from some random low-value website, the attacker has an easy way to figure out your master_password and thus your site_password for actually valuable sites. You have no way to defeat this outside of changing your master_password - which changes the site_password for every site you use which more or less defeats the entire purpose of this scheme.
Realistically, the biggest security benefit of this scheme is that almost no one uses this type of stateless password manager because of the other obvious ergonomic problems (ie: you have to somehow remember the value of counter and settings that you picked - which is a pain to do for more than a couple websites). But, that is security through obscurity which has long been (rightly) viewed as bad security.
Don't use this. Don't use any stateless password manager. It's fake security.
Looking at https://blog.lesspass.com/lesspass-how-it-works-dde742dd18a4... - its implemented using PBKDF2 w/ 100,000 iterations with SHA-256. 100,000 iterations is nice as that is on the higher side for what I understand the normal number of iterations of PBKDF2 to be. However, PBKDF2 with SHA-256 is an ideal algorithm to brute force on a GPU. More modern password hashing schemes such as bcrypt, scrypt, or Argon2 impose a much more significant memory penalty which makes them much harder to brute force. But since its impossible to change how F() works without changing every users's password, this scheme will forever be stuck using PBKDF2 with SHA-256 and each year as new, more powerful hardware comes out, this scheme will continue to get weaker.
A thought experiment... which probably doesn't change the big picture... but it's interesting...
Suppose the initial implementation chose an ill-suited/fast/cheap hash (like MD5). The developer facepalms appropriately, changes course, and updates the implementation to support an expanded list of 4 hashes (1 old/weak/cheap hash and 3 new/strong/expensive hashes) - and you track the hash in the same way as the counter.
Fast-forward a bit. Mallory eavesdrops, learns an example password, and starts a brute-force attack for the master password. He doesn't know which hash to use, so he has to try all of them. On the surface, the choice of hash is just 1 or 2 bits of entropy... but the resource impact on Mallory is driven by the (in)efficiency of the new hash(es), so it has an outsized impact.
In anticipation of upcoming hardware, the developer issues annual updates with another (slower) hashing option (PBKDF2 w/100k iterations => 150k iterations => 200k iterations). This muddies the waters for new brute-force attacks. It's kind of a neat notion that the mere existence of a newer convention could retroactively raise the cost of a brute-force.
Alas, it's not real. Because we're not just concerned that Mallory is an eavesdroper listening to a random password - we're concerned that Mallory is a website-operator who takes user-registrations. In that case, he can simply log the time when the user or password was created -- and thereby rule-out future hashing conventinos.
In general, these types of utilities don't treat the state (counters, password rules, etc.) as a secret, so I wouldn't count on the hash type being secret either. The security of this type of scheme depends almost entirely on not being able to reverse a presumably known key derivation function such as scrypt.
This is true for passwords that are hashed and stored in some site's database. Someday computers with be powerful enough to easily break the hash currently stored with your bank account login.
Masterpassword gives me a huge variety of different types of passwords of minimal to high strength. Hell it even let's you use a personal password or key, which is something I learned just now.
Say I only used the most powerful password type and have a very strong master password with 7+ words generated with diceware, do you think it's still fake security? Genuinely would like to know.
In a stateless system, you have to remember which options you picked. The more options there are to pick, the harder it is to remember them. I would suspect, that in general, most people pick from fairly limited number of options regardless of how many are actually available. The key point is that the options function effectively like a salt in a traditional password hashing scheme. And while a salt is generally a 32 or 64 bit value, there are almost certainly not nearly as many combinations of options that you would realistically pick from - unless you can remember a number between 0 and ~1.84e19 for each site that you login to.
A stateless password manager means that any password compromise on any site that you have a password for allows an attacker to mount an offline attack against _every_ other website that you have a password for. If your master password is truly uncrackable, you'll be safe. But you'll only be safe if an attacker decides to give up after a few billion guesses. Some passwords are that secure. I'm not aware of any evidence that most people's passwords are, however.
If you really have enough confidence in your master password that you don't have an issue with an attacker being able to mount an offline brute force attack against it, go for it. But in general, I think it's a very bad strategy for the vast, vast majority of people.
Compared to a regular stateful password manager? Absolutely, for all the reasons mentioned by the parent poster. Stateful password managers are just more secure since the sitepasswords have no relationship between each other, so individual sites leaking a site password does not give them any possible attack.
Compared to using just the master password for all sites? Well, a stateless password manager is probably better than that at least.
This post is a fake analysis. Assuming the master password is very strong, let’s say 128 bits of entropy, it doesn’t matter if a site stores a generated password in plain text since finding the master password is equivalent to cracking PBKDF2 with 100k iterations. Another comment said this is doable, but if someone is using a very strong master password you are not going to crack it.
Your assumption is that the master password is uncrackable - but do you have a reasonable source that suggests that most people's password fall into that category?
Compare a stateless system with a stateful one - one where the actual passwords are random and stored somewhere. In the stateful system, figuring out the password for one site provides no knowledge about the passwords for any other site. Yes, a stateful system does have a single point of failure - if you can guess the master password, you can get all of the other ones by logging into whatever site is storing the password database - but that is no different than in the stateless system. What is different is that that cracking the master password is probably subject to a rate limit by the site that stores the password database making a brute force attack infeasible. You could, of course, in theory, steal the entire password database and attack it offline to defeat the rate limit - but that requires breaching the system that store the password database. While that is doable, at least you are limiting your trust to a single entity (whoever stores the password database) to prevent breaches. In the stateless system, however, you are hoping that your master password is uncrackable (it probably isn't) and that every single website you have a password for is also unbreachable (which they definitely are not).
Please try 1Password or LastPass before you shoot yourself in the foot with something so unjustifiably insecure and functionally-hobbled as this. You'll see those apps are no hassle at all, this stateless approach really doesn't gain you anything but does cost you a lot.
What are the upsides to a stateless approach? Convenience/simplicity? When you look at the guessing game you have to play to get the right login with this, or the eventual personal state management you'll need to track exceptions, it's certainly not simpler in practice. Price? LastPass is free for personal use. Works offline? So do LastPass/1Password so long as you set them up first. AFAIK there are literally no upsides to this.
What are the downsides? Review this thread, all the big ones have been mentioned and there are more:
- Master password cannot be changed
- If master password is compromised, all your passwords are compromised, regardless of device. (For proper password managers, master password gets access only on the physical devices on which it's been synchronized and you can revoke a stolen vault's online authorization remotely.)
- Rotating a compromised password requires remembering you did it, or a guessing game to find the right iteration of a counter variable.
- Master password must be typed in full every time to get a site password. This will encourage you to have a short master password.
- Doesn't autofill login forms for you, requires copy/tab/paste.
- Master password is typed into a web browser for every single password. Browsers are generally a less secure runtime context than a native application.
- Doesn't remember the email/username you used for services.
- Exceptions to password rules imposed by websites (length/character requirements or exclusions) cannot be tracked
- It's not always clear what the name of the site/service is to use for the hash function inputs. Is is mybank.com or secure.login.mybank.com? Another guessing game.
- Many items above mean you will end up wanting some kind of state to track the stuff this doesn't deal with, and now you've implemented your own state solution which is surely far worse than what LastPass or 1Password have built.
One "upside" people might claim is that LastPass/1Password state servers can be hacked (LastPass was hacked once I think?). But this actually isn't nearly as bad as it sounds. If attackers get a bunch of (encrypted) vaults, they still have to brute force every vault individually. Furthermore, these providers have everything to lose in terms of reputation if they are hacked, so are financially incentivized to maintain the highest degree of system and software security. Compare that to this solution, which in every way trades aways security and has basically nil financial incentive for secure implementation.
I keep editing my post to add more reasons not to use this thing. Don't use it.
> Stop wasting your time synchronizing your encrypted vault.
Is this... actually a problem for anyone anywhere? Is this satire? Like when someone made a networked string concatenation service and made it available on Docker?
No, it's not a problem. I don't remember when I last "wasted time synchronising my encrypted database" because Bitwarden does it behind the scenes without my knowledge.
