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

Brian Hankey bhankey at gmail.com
Tue Dec 29 05:04:33 EST 2015


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 at 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....)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.randombit.net/pipermail/cryptography/attachments/20151229/5217be0e/attachment-0001.html>


More information about the cryptography mailing list