Hacker News Reader

Comment by _xnmw | Hacker News Reader

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.

View on HN

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.

> too expensive to get a cert

What? Has he never heard of LetsEncrypt or CloudFlare?

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.

May I ask why? If you have to maintain state with a Google Sheet, syncing is necessary. What benefit is there to this approach?

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.

It's not stateless though - it's a (hopefully) eventually consistent heterogeneous distributed database.

It's probably 90% stateless, with username being email and version being 1, plus probably remembering the exceptions to sites you use often.

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

So you keep your stateless password manager state in a spreadsheet?

you should just store all 110 passwords in your google sheet while you are at it

The point is that the master password is not stored on this sheet.

> 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.

They have a sign in mode to remember unique information about the password, without having to actually store the password.

At that point what is the benefit? Syncing state is inevitable then. Also you still can’t change your master password.

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.

And then you can have something that syncs that local cache between computers, and you have a complete solution.

Counter and username is low-security information you can shove in Google Drive.

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.

Remembering a username is a non-issue, much easier than remembering a high-entropy password, and can be usually recovered easily.

For a counterfield you can just use the domain name of the site for consistency.

Counter is so that you can rotate passwords. If a site forces you to update to a new password, you increment the counter.

But now you need to know how many times a particular site has forced you to change your password.

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?

Reply on news.ycombinator.com