Hi Jeffrey, I sent a long winded reply that has been stuck in moderation for a couple of days so I'm going to break it into two parts. Also found an interesting new link to add to the discussion today.
Let me make sure that I have been clear about what I propose, Thank you. I may very well have entirely misunderstood what your system did, as reading a bunch of PHP and JavaScript embedded within some HTML really communicate things clearly. Yea this is not a very clear demo. I will probably take it down. because this is as much about how to easily remember the unique passwords as it is about the amateurish demo we made… You have four inputs to this algorithm: 1) String 1: This can be anything but I propose an easy way to remember something that is unique. Ah, so you want the user to remember something specific for each site. No… remember a rule that can be used to transform the name of the site in some way. Not a master password and not simply “site name” could be as follows: Perform a transform on the site name, one that is easy to remember but hard to guess. It seems to me there could really be a lot of variations here still. Char for letter substitutions, exclude vowels, double vowels, exclude consonants, double constants, cases, do you include or not include the subdomain, do you include or not include the top level domain, do you include the (.), do you append anything to it and so on. Each one of those decisions is roughly one bit (except for “what you append”). So you’ve got 8 bits in there, if you are equally likely to choose each alternative (say, flip a coin for each decision). A am going to guess that if people are expected to remember scores of these, they will make the same decisions for each. So the individual remembered passwords unique for each site will not be independent of each other. (And are highly guessable). Every single one of our transformations are part of the standard rules sets that come with password cracking tools such as John the Ripper or Hashcat. Yea that’s true. I am vaguely familiar with Ripper. But there are a lot of rules you can combine. If you are doing the same for every site you can combine many “rules” and have it not be that hard to remember. Are you sure the possible combinations do not provide more than 8 bits? You could even add more and still be easy to remember… add D0G to the end if the service starts with a vowel and C@T if it begins with a constant, nothing if it’s a number. If we talk about www.gmail.com we could get something like: MoClIaMgWwW or gmAIl or LiaMG or WWW.gMaIl.COM <http://www.gmail.com/> and so on and so forth. Perhaps even running *just* this through a hash and then ensuring an upper a lower and a special char would be sufficient alone to be much more secure than any average password? Except that if one of those constructed hashes is captured (as plaintext), then someone running a cracker against it can figure out what your remembered secret is. From that, they can make very very good guesses about your system for constructing those. I am not sure I understand how they could do that unless they know what system I used to create the hashed passwords in the first place, which seems like a pretty big assumption to me. Since we’ve already decided that a password system like this is too cumbersome and inconvenient to become mass market, why would a random person assume that I used such a system in the first place? Because remember - my password if stored in plain text is a hash of four other hashes that were stuck together and hashed. Unless I’m missing something to do the kind of attack you’re talking about the attacker would need to know that the password is a piece of a hash that is a hash of four things, he would have to have a lot of assumptions in there. Am I missing something? Even if a breached site hashes their passwords, a cracker who suspects that you are using your system will just tune their hash cracker to first run through your hashing and then the sites. That is, if you have user knows P, a low entropy password for site i User: prehash := Hc(P) // Hs is client’s hashing scheme User: Send prehash to server as password Server: h := Hs(prehash) // Hc is server’s hashing scheme then a password cracker just need to run their guesses, P’, through Hs(Hc(P’)) == h It really isn’t any more trouble than what they already do in password hashing. Your remembered constant PIN and your very low entropy remembered site specific password remain easily crackable. And once one is cracked, the PIN is revealed and large parts of the user’s “memorable scheme” is revealed. The only advantage of the prehash is if a site stores passwords unhashed (which happens). In the paper that I pointed to, they do use PBKDF2 in the client hashing, which helps some in that case. Yes I realize this… but why would anyone go to that trouble when there is so much other low hanging fruit? Plain text passwords or passwords that were only hashed once. I agree if a skilled adversary is specifically targeting me, this is not particularly sophisticated but in terms of protecting oneself from mass hacking, mass data dumps, etc. It still seems like a decent solution to me, if you can deal with the hassle/inconvenience, which seems low to me personally compared to having all your accounts compromised. But again, maybe I am missing part of what you are saying. 2) String 2: This can be anything also but I propose some kind of a number (or PIN) that could be the same or could have some additional trick added to it such as 1010 + (1 if site starts with vowel or 2 if site starts with consonant). You can be as fancy or simple here as you like but there are still things you can do to make it not the same every time while still easy to remember. Balance between convenience and security as you wish. Again, I think the same objecting applies. Granted. 3) Special char (optional): Everybody can remember one favorite special char easily. (Perhaps this field could be eliminated though, read further). Being generous, lets say that people are equally like to pick among 10 special characters (I’ll bet that “*” and “!” will actually show up more often). That give you another 3 bits. And again, once discovered once, it is discovered for all passwords. Agreed, this was just the first crude way to force a special char to conform to password requirements, I’m sure there is a better way which probably even involves eliminating this field so that then there are only three. 4) Version: defaults to 1 but nothing would stop a user from starting at any other number such as a meaningful date or some other obvious thing. The point here is that by incrementing the number you can deal with forced password changes but keep the rest the same. Probably the least convenient of part of this whole scheme but that’s one of the many reasons I sought out some input. In any event I use a LOT of different services and don’t find this to be so common an occurrence, perhaps once every six months I have to change my password to an “important” site. The unimportant stuff like web forums and mailing lists and things like that never force changes.. I also suppose that given the variation already introduced above it would be OK even to write down your version # or store it in a Google doc, etc. although that certainly isn’t ideal or convenient either. It is not so hard that when you forget google is on 2 and not 1 to just try to 2. When it gets to the point where your versions are all over the place you can just create a new rule for input #1 and start from the beginning again. So you keep on adding bit by bit (pun intended) a burden to the user. Note that you are also asking the user to remember which scheme and set of rules they used for which site. It’s really just one thing to remember. What scheme do you use to transform site names. The rest of it is trivial. But one thing this discussion is leading me to is that maybe this is equally good (or equally bad, as the case may be) if you just have two fields - the site transform with the “rules” and the version number. You still have a hash of hashes and just a piece of a hash of hashes as a password. I’m sure you can poke a million holes in my idea, but is this really worse than: 1) Using the same password for everything, even if it’s really strong? No. Your scheme is better. 2) Using weak passwords? Weak but unique and independent passwords are better than your scheme. (But people won’t do that without help) Really? How can that be? Anywhere a password is stored in plain text (few and far between these days I guess but it happens) it can just be instantly exposed. If the password has just been hashed once using a common algorithm existing rainbow tables would easily uncover it. In my cash the only thing underneath the hashed password is another hash. Am I missing something? 3) Using simple transforms alone like "GOoGle1234(“? Your scheme is pretty much equivalent to that except that you use the same simple transforms for all or most sites. Well yes it is but doesn’t it add at least a little bit more entropy? And plus hypothetically, if someone got the password file of a remote server and converted it to plain text (through whatever means) everyone else passwords would sit bare, naked and exposed while mine would be buried under another level of hashing. Isn’t this true? Why is this of no benefit? Granted if everyone used “my system” then the hackers could trivially adjust all their tools to use “my system” but since we agree my system is too troublesome for the mass market… why would they bother? Keep attacking the people with bad passwords and no “system”. I guess that I am probably missing something obvious here and certainly defer to you as an expert in the field but I’m just trying to better understand why it would be virtually worthless to add a couple extra layers of hashing over ‘8080GoOg!” or the like. If we rule out typical password managers (cloud or local) - what other alternatives exist that are better? Well you have ruled out what I recommend as the most practical and available right now approach. But continuing, I am very intrigued by the FIDO U2F scheme. I’ve seen proposals to get rid of passwords come and go for 20 years. So I’ve learned to be skeptical of them. But the FIDO Alliance has my attention. I’m more optimistic about it than I have been about proposals to “eliminate passwords” for a ver long time. I am not ruling them out to be annoying or to be a jerk but only to explore the possibility of something that is mostly memory based, yet still far more secure than the alternative to those that do not use password managers. And I would assume we will agree that there will be a subset of the population that will not want to use typical password managers due to either paranoia of the cloud or inconvenience of having to install something on every device you access the net from or both? Or do you think that’s too much of an assumption to make? My perhaps incorrect hypothesis is that no mere mortal can remember truly unique passwords for all the sites and services they’re likely to use. Therefore, *unless *they are using one of the traditional password managers which is storing all of your passwords either locally or in the cloud under heavy encryption with one complex master password, they are probably using either: some variation of the same password everywhere or some really transparent rule based scheme… So as yet another alternative… this is the question I am trying to answer, if poorly or amateurishly. My hope is that maybe in discussing and considering it something much more workable might come out of it… and if not, nothing ventured nothing gained right? I don’t mean to downplay the decades of professional experience others have in this field. (to be continued in part 2....)
_______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
