On 2015-12-20, at 4:33 AM, Brian Hankey <bhan...@gmail.com> wrote: > 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. > 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. > 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. > 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 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. 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. > 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. > 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. > 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. > 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) > > 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. > > 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. > This is the question I’m getting at. I’m sure that the current > implementation is awful as you’ve already pointed out, I only wanted this is > a demo of the concept. > > If anyone is game I would love to have a practical challenge. Let’s say we > are using SHA2. Let’s say I will tell you the following about my inputs: > > 1) It is a transform on the domain www.facebook.com and I will even say it > does not include the www. or the .com > > 2) My number is a date of some kind. > > 3) My special char obviously you will know, & > > 4) I will not tell you my version. > > How quickly could do you think this could be cracked really? If this answer > involves any of the following: “it would take quite a bit of time,” “it would > require some pretty decent CPU power,” or “it would need someone that really > knows their mathematics and cryptography well” It would require someone who knows how to use something like John the Ripper or Hashcat. There are thousands of such people. Using SHA-256, a GPU acceleration would allow them to probably run millions of guesses per second on a computer that costs less than $5000 dollars. I’m not going the take the challenge, but my off the cuff guess is that they’d have a 75 chance of guessing within 4 hours after initial set up and configuration. (I should note that I don’t do a lot of password cracking myself, but I very much follow what others are doing). You can make it harder for them by increasing the burden on the user. But every time you do that, you make it more likely that the user will use the same system for each site, thus increasing the risk that cracking one will need to a crack of all. > The most exciting thing I have ever read along these lines is this: > http://www.extremetech.com/extreme/133067-unbreakable-crypto-store-a-30-character-password-in-your-brains-subconscious-memory This, and things like @inproceedings{BonneauSchechter2014:USENIX, Address = {San Diego, CA}, Author = {Bonneau, Joseph and Schechter, Stuart}, Booktitle = {23rd USENIX Security Symposium (USENIX Security 14)}, Month = Aug, Pages = {607--623}, Publisher = {USENIX Association}, Title = {Towards Reliable Storage of 56-bit Secrets in Human Memory}, Year = {2014}} https://www.usenix.org/conference/usenixsecurity14/technical-sessions/presentation/bonneau are great. But the problem is that there is so far no testing (or reason to believe) that people will be able to do that for dozens of independent passwords. So those training schemes are good for something like a Master Password for some password management system, but they are not useful for the scores of passwords that people need to use. Cheers, -j _______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
