4 ms·

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

• tempodox 11y ago
  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”.
  • reitanqild 11y ago
    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.)
    • walterbell 11y ago
      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.
• opcvx 11y ago
  Where should the state be kept, on a server?
  • w8rbt 11y ago
    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.
    • opcvx 11y ago
      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.
    • spott 11y ago
      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.
    • acdha 11y ago
      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.
    • saidajigumi 11y ago
      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.
• taeric 11y ago
  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.