Hacker News Reader

Comment by w8rbt | Hacker News Reader

The fundamental design flaw of all of these compromised password managers, keychains, etc. is that they keep state in a file. That causes all sorts of problems (syncing among devices, file corruption, unauthorized access, tampering, backups, etc.).

Edit - I seldom downvote others and the few times I do, I comment as to why I think the post was inappropriate. What is inappropriate about my post?

Few people stop and think about the burden of keeping state and the problems that introduces with password storage. Many even compound the problems by keeping state in the Cloud (solve device syncing issues). It's worth discussing. There are other ways.

View on HN

The fundamental problem with this idea is that the computer has to store your password somewhere, for it to be able to check it. Now, these particular passwords could be kept only on the server, but they are still kept. In a file. On a computer.

Your comment comes across as somewhat silly and akin to saying that the problem is we have to transmit the passwords (or some derivative data) across the internet to do business with someone. Yes... that is a facet of the problem. It is also a facet of how work gets done.

No idea. I can't even find a single obvious interpretation of what a downvote is supposed to convey. I bet it's not the same thing twice for the same person on the same day. If it were up to me, I would remove the power-to-downvote from the API. If I really do oppose a comment, I should give a reason rather than just a “bit with a negative sign”.

One reason is people using HN on mobile devices. This used to be my "reading account" so I couldn't downvote accidentally but now I have crossed the barrier with this one as well.

Not saying that is what happened here though (because I down't know.)

Yes, we need the upvote and downvote icons to be moved to opposite ends of the comment title, which would eliminate the 1mm targeting challenge.

Where should the state be kept, on a server?

No where electronically. A simple word or phrase in the user's mind would do.

Rather than being stored for later retrieval, complex passwords could be generated on-the-fly (when needed) using this word/phrase as input combined with other input such as URLs, hostnames, service names, etc.

That's hard to manage outside of a few specialized environments where you have total control of the user and applications. The problem which comes to mind is that there's no way to use that system when so many sites have incompatible restrictions on length and character set – i.e. I have accounts on systems where the minimum password length is longer than the maximum somewhere else – and I'd still need a manager to track my random answers to security questions.

Rather than trying to make small improvements in the inherently-limited password model we should be focusing on changing the model entirely to depend less on what a human can comfortably remember: that's things like SSO to avoid the need to manage hundreds of accounts and also things like U2F to use strong public-key encryption.

IIUC, you're talking about using what amounts to a user-managed password-generation schema. This seems like a weak (re: entropy) and ultimately very user-hostile approach to password management. Having known people who use such approaches, they still have to remember at some potentially distant time just what cocktail of fields they used in their password formula for this site. That is, the burden of password memorization remains but they don't gain much for their trouble.

I hear of such schemes from time to time but I've never seen them subjected to real attack analysis. I strongly suspect that these mostly generate surprisingly weak passwords.

What is fundamentally different between your suggestion and an approach where passwords are kept in a file that's encrypted with a password that's kept only in the user's mind?

In both cases you have a bunch of data that mostly represents the passwords, but you need one final component to actually unlock it, which is the master password. What's the advantage of your proposal?

You method would require that pass everytime a password is fetched or generated. Similar to the UAC confimation on Windows. Remember how annoying that was, everyone turned it off.

The problem with this is that different passwords have different requirements, which must now be remembered and entered every time you need that particular password.

I suppose "immutable state" would be a nice compromise, but the method is fundamentally less flexible than something with state.

Reply on news.ycombinator.com