Re: [cryptography] Hi all, would like your feedback on something

[Jeffrey Goldberg]

On Dec 23, 2015, at 2:18 AM, Brian Hankey  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 

[cryptography] Fwd: Hi all, would like your feedback on something

[Brian Hankey]

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  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 

[cryptography] Fwd: Hi all, would like your feedback on something

[Brian Hankey]

Here is another interesting link about alternative kinds of passwords:
http://phys.org/news/2015-12-images-codes-alternative-multiple-device.html
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

[cryptography] Fwd: Hi all, would like your feedback on something

[Brian Hankey]

(part 2 continued...)

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.



If I hear you correctly you are saying that the hacker knows I use this
particular password “system”.  He knows that I use some form of transform
on domain name without www. or .com, that my number is a date of some kind,
that my special char is &, he doesn’t know the version.  You are saying
given all of that you would still need someone who understands password
cracking technologies, has specialized hardware (even if not crazy
expensive), would need to spend some unknown time X on setup and
configuration and then some number of hours on this dedicated machine just
to crack my password?

I would consider that a huge win.  The last time I played with John the
Ripper (at least I’m pretty sure it was that, could have been something
similar) was in the late 90’s using a 486dx 66 MHz with 8MB of ram and some
version of Linux. I realize that the algorithms used today are much better,
but then again so is the hardware.  What I remember was cracking several of
the weakest of the weak passwords within minutes, within hours or perhaps a
couple of days you could easily crack 10-20% of the passwords.  Maybe those
users were particularly stupid but somehow I don’t think so. And this was
just working mostly with the out of the box configuration.

If we are fully understanding each other here, then what I am proposing
does as much, or perhaps even more than I had ever hoped. I thought it
would take a lot more work and development for me to even get to this
point.

Another question of interest me in this case, again assuming I understood
you correctly in the first place is, how easy would it be to search for the
people using this weak system, and would somehow be any easier or more
fruitful than just going after the average passwords?



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.


Wow fantastically interesting leak.  I will watch the presentation and
perhaps comment more later.

What do you think about this one? http://www.nimbusid.com/  While the setup
and login is a bet lengthy, I find it to be extremely user friendly. The
demo requires 3 objects with 7 attributes… I don’t know if whatever math
they are still using would still workout but personally I could see it
being easier to deal with by having more objects but less attributes. I
very much like this system but I can imagine that there must be a reason
why it hasn’t taken off like wild fire yet. Even if