Re: @stake Security Advisory: NetZero Password Algorithm

[mouse () RODENTS MONTREAL QC CA (der Mouse)]

> > It is unfortunately common practice that applications which allow
> > users to remember their passwords as a convenience rarely encrypt
> > them but instead opt to simply obfuscate them.

> Actually, it's an unfortunately (verging on ridiculously) common
> practice to think that there's any difference between encoding a
> password using a fixed algorithm and "encrypting" a password using a
> fixed key.

Most of what Dan says here is absolutely correct.  Certainly this point
is accurate: encryption, even if it's "real" encryption (3DES,
Rijndael, pick your favorite) is only as good as the secrecy of the key
involved.  If the key is fixed, it's a total pushover.  If the key is
stored "in the same place" (the same disk, the same database, whatever)
as the ciphertext, it's almost as much of a joke.

> Of course, the obvious question is how a system verify the
> correctness of a password without actually posessing that password.
> [...] Simply store a [] one-way hash of the password.

Right.  And indeed I wouldn't even quote this except that shortly
thereafter follows

> One reasonably simple solution(translation:  somebody contact me if
> this is in error) for those who have implemented a respected
> encryption system(RC4, Blowfish, even *DES* qualifies) to obfuscate
> access to their password database is to encrypt passwords with
> themselves--i.e. encrypt "fg&^2jfa" with the key "fg&^@jfa".

This - aside from what I hope is a typo in one of those two strings -
is, essentially, using the encryption algorithm as a rudimentary
one-way hash function.

This works, in a sense.  However, I recommend against it unless the
encryption algorithm in question has been specifically analyzed for
strength in this use.  Any known correlation between plaintext and key
will potentially make cryptanalysis easier.

If you really want to do this, use the password as the key and encrypt
a constant.  This leads to a known-plaintext attack on the
cryptosystem, but this is a well-known and much-studied type of attack,
and as a result a cryptosystem's resistance to it is the sort of thing
you should be able to find in whatever source you picked the system
from.  (And if you do it with a cipher that's no good against a
known-plaintext attacks, well, you made a stupid choice. :-)

If you want to increase the work factor, then for every password, pick
a random constant, encrypt it with the password as key, and store the
random constant and the encryption of it together as the hash.  (Of
course, this runs into the problem of getting good random bits.)

> The most common reason why hash systems aren't used, of course, is
> that often the plaintext is needed by the system for purposes outside
> of verification.

Of course this is the real thorny point.  Most of these "remember your
password" systems need the password in the clear in order to proxy for
the user to some other service which demands a cleartext password to
authenticate (or moral equivalent, as with APOP authentication to a
POP3 server - you don't send the cleartext, but you need it).

Unfortunately there is no way around this, in a sense - if the software
can authenticate itself as the user without the user needing to provide
anything, then an illicit piece of software running in its stead can do
likewise.

                                        der Mouse

                               mouse () rodents montreal qc ca
                     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B