Lesspass – open-source stateless password manager
lesspass.com
lesspass.com
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.
salt = (
password_profile["site"]
+ password_profile["login"]
+ hex(password_profile["counter"])[2:]
)
`_insert_string_pseudo_randomly` seems overcomplicated compared to just putting `string` at the end, too.
But some websites (like some games) in the first category have mandatory 2FA.
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.
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).
In addition, certain sites log you out after the change-password action and require you to explicitly login right after.
Explicitly not storing the password sounds.. brave? stupid?
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.
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)
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.
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...
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)
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?
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.
What? Has he never heard of LetsEncrypt or CloudFlare?
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.
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.
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
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.
I'm still not sure that this system is a good idea, but I think "where do I store the non-password bits" isnt a big concern.
For a counterfield you can just use the domain name of the site for consistency.
But now you need to know how many times a particular site has forced you to change your password.
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.
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?
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.
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.
They're just hard enough to fake that a password can become unnecessary for casual security.
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" phrase and the idea of "profiles"
There are still many active ports of ports of PasswordMaker:
https://www.google.com/search?q=github+passwordmaker&oq=gith...
Heres the original web version:
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. )
Funnily different master passwords generate a different output space ( good if you want special characters), which is a tiny bit worrying.
I switched to this from my own algorithm which I mentioned here about a decade ago. https://news.ycombinator.com/item?id=2431480
How do I use it on my phone then?
> or store the database in sftp
SFTP where? The "cloud"?
> Why do people try so hard to use "cloud" based clearly unsecure solutions?
Because it is the easiest and most convenient and most useful.
I've switched to Bitwarden a few months ago, and I couldn't be happier.
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.
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.
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).
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.
https://github.com/dheera/scripts/blob/master/passgen (generates passwords)
https://github.com/dheera/scripts/blob/master/passenter (generates and types them in with a 3 second delay to switch windows)
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.
In practice I use this: https://www.passwordstore.org/
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.
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.
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 ....
An easy solution would be to append "A1!" to all generated passwords.
> You also can self host your LessPass Database
From a local stateless solution to managing a server, that escalated fast.
> An easy solution would be to append "A1!" to all generated passwords.
Your easy solution does not even work on the example you picked on.
I switched to BitWarden and am much happier now.
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
(Also open-source: https://github.com/Cretezy/MasterPassX)
As a shameless plug: https://derivepass.com/
This way password manager wouldn't have to store them in cleartext either. Would be pain to enter them manually tho...
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.
The prototype works, but is super rough. https://github.com/syllable-hq/skipper
function loginAction(evt) {
evt.preventDefault();
const password = inputPasswordEl.current.value;
props.db.getAllUsers()
.then(querySnapshot => {
const users = [];
querySnapshot.forEach(function (doc) {
const userObject = Object.assign({}, doc.data(), { id: doc.id });
users.push(userObject);
});
const userFound = findUserMatch(password, users);
export function findUserMatch(password, users) {
return users.find(user => {
return bcrypt.compareSync(password, user.userKey)
});
}
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: '/' });
}
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);
}
I would recommend Bitwarden instead.
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.
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.
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.
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 what?
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.
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).
So don’t use a brute-forceable master password…
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.
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?