On Dec 23, 2015, at 2:18 AM, Brian Hankey <bhan...@gmail.com> wrote: > > I sent a long winded reply that has been stuck in moderation for a couple of > days
I believe that this is because your are sending email with a text/html part. Most mailing lists will reject such things. >> 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. So the attacker only needs to discover this rule once. And the rule is going to be the same sorts of things that crackers already use. You’d be surprised at how many passwords in the LinkedIn dataset were things like Iink3d1n Crackers would barely be need to change their transforms to go after that. And once they’ve cracked one of them, they will know your rule for all of them. >>> 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? Please take a look at something I wrote a while back: https://blog.agilebits.com/2011/08/10/better-master-passwords-the-geek-edition/ >> >> 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? Using a password generation scheme that is unlike what other people use does offer you some protection against non-targeted attacks. But if your scheme only works as long as few people use it, then you shouldn’t be advocating it. And as for more targeted attacks, you’ve already described your scheme in a public place. I like to take a Kantian approach to password generation schemes: They should remain good even if lots of people use it. Offering advice that becomes bad if people actually follow the advice isn’t really good advice, is it? > Because remember - my password if stored in plain text is a hash of four > other hashes that were stuck together and hashed. And remember. That is just a one-round pre-hash to an attacker. You seem to think that prehashing your password endows it with magical powers. So as I said, >> 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? But it isn’t much more trouble. This sort of thing is what password crackers do all the time. Furthermore, cracking yours is valuable because once done for one site, they will see your transformation rule, and will be able to go after all of your other passwords. There is also a funny thing about the economics of password cracking. Criminals are competing with each other. So if there is a public or semi-public breach data going around, a password that has been cracked by lots of criminals is of far less value than one that hasn’t. So there is an incentive to go after some of the odd-ball ones. > Plain text passwords or passwords that were only hashed once. A password that is hashed twice instead of once just isn’t a noticeable barrier. >>> 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? Because your passwords aren’t independent of each other. Once one is cracked, they are all cracked. > 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. Think it through. If passwords are stored in plain text and are captured, then whether the password is “12345” or “f9975ea34426551975f5d3b382ca99f4” it can be used on that site from which it was captured. It doesn’t matter whether it is weak or strong. But if the person using weak passwords is using unique passwords, than “12345” isn’t going to help the attacker breaking into other sites. But with your scheme, you have given them something that if worked on a bit can be used to break into your other accounts. >>> 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? Sure. For any single password you go through a lot of work to add a tiny bit more strength. It is hardly worth it, and you still have the problem of having passwords that are not independent of each other. > 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? Because the thing that is laid bare is your actual password for that site. To use it against that site, nobody needs to crack your hash. > Granted if everyone used “my system” then the hackers could trivially adjust > all their tools to use “my system”, Good, I’m glad that you see that. That one extra layer of hashing buys you very little. > 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”. As I said above, if you advocate use of a system whose strength depends on people not following your advice, well you just have to hope that not too many people start doing the same thing. > I guess that I am probably missing something obvious here and certainly defer > to you as an expert Well, I feel like I’ve been repeating myself. I think that you fail to understand the significance of my criticisms. >>> 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. > > I am not ruling them out to be annoying or to be a jerk Thats fine. Password managers are not an ideal solution, they are just (in my possibly biased opinion) the best option available today for most people. > but only to explore the possibility of something that is mostly memory based, Definitely a worthwhile thing to do. > yet still far more secure than the alternative to those that do not use > password managers. But you are not “far” more secure with your system. You go to a lot of effort for something whose gain in security isn’t very big at all. > 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? Only a tiny portion of the population use password managers. But people who are worried about the security of password managers should try to find something that offers them more security than a good password manager instead of adopting something that offers far less. > 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. Correct. (Though I have actually met an expecting. She has an eidetic memory and has had high level security training on password choice.) But yes, that is the problem we are trying to solve. And in stuff that I snipped, I said that I think the solution will be to do away with passwords. But until that time comes, password managers remain a superior solution to every alternative I’ve seen. And that includes versions of your scheme that are far superior to what you have actually worked out. > 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… Correct. > 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? But again, your scheme is only slightly better than “some variation of the same password everywhere”, yet it is probably harder to learn and use than most decent password managers. My fear is that if something like your scheme does catch on, users of it won’t realize that it is only slightly more secure than the “some variation of the same password for each site”. That is, it might give them an illusion of security that isn’t there. It’s like suggesting that you use rot13 because although it isn’t as good as serious crypto “it is better than nothing”. A false sense of security is often worse than nothing. Cheers, -j
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
