[jadmin] Re: jabberd14 'crypt' password storage in postgressql

Wed Jun 13 08:10:35 CDT 2007

IANASE (I am not a security expert), i.e. I'm not paid to work in security,
but:

If the password is stored encrypted in the database, then at some point in
time, the software has to decrypt it to check it with the password (or
derived value) supplied by the user.  If the software can decrypt the
password, then so can the database administrator, because most of the time
he has access to anything the software does.

That being said, encrypting the password in the database does add:
 a) the administrator can't "see a user's password by mistake"
 b) if the database is stored on a separate machine with vastly different
ACL's then the DBA can't get the decryption key.
 c) ad-hoc sql queries made via loop holes in buggy software can't see the
passwords.

Comments:
 a) you can achieve the same by base64 encoding the password (much like
BASIC auth does).  Unfortunately some people think that this adds encryption
(which it doesn't)
 b) I bet 90% of the time, if the DBA can read the password field, then he
had access to the decryption key too.
 c) This is about the only useful reason I can think of to encrypt (as
compared to obfuscate/encode) the password.

I think there are several arguments here, but basically they are:

storage:
 1) storing passwords in cleartext is a bad idea (for reasons above)
 2) storing hashed passwords doesn't really gain anything (because you can
use a modified client to submit the hash directly) - this includes
pre-hashed data that can be used by DIGEST-MD5 authentication

transmission:
 3) sending plaintext passwords over the wire is a bad idea (duh)
 4) sending plaintext passwords over SSL secured wire is not preferred (MITM
attacks, etc)
 5) sending hashed passwords over either of the above (see point 2 above,
hash is the same as plain, for modified client)

 6) sending derived information over any wire (plain or SSL) is fairly
safe.  As long as it's secured with nonces and timestamps that prevent reply
attacks.  (This prevents against MITM attacks, because the derived
information will _always_ be different.  DIGEST-MD5 is an example of this)

It is only possible to send 100% derived information _if_ some sort of
plaintext (or plaintext derived data) is stored in the database.  You can't
have both.

A quick note on hashes:
 i) storing plaintext allows a compromised database to be used to attack the
user's account on the current and on other realms.
 ii) storing unsalted hashes allows a compromised database to be brute
forced (even with rainbow tables, etc). (but can't be used for 6 above) (two
user's with the same password will have the same hash)
 iii) storing salted hashes (where the salt is chosen by the administrator),
goes some way to protect against brute forcing - assuming that the attacker
doesn't know what the salt is. (attacker must generate rainbow tables from
scratch - I think) (but can't be used for 6 above) (two user's with the same
password will have the same hash)
 iv) storing salted hashes (where the salt is randon), goes a long way to
protect against brute forcing (removes rainbow table attack, etc). (but
can't be used for 6 above) (two user's with the same password probably won't
have the same hash)
 v) storing salted hashes (where the salt is based on known values like:
username and realm), allows the use of 6 above, and protects against the
data being used to attack other realms. (two user's with the same password
won't have the same hash)

vi) Con: Once you've stored a hash, you can't automatically 'upgrade' it to
a new hash.  The best you can do is store both old and new (eg: md5 and
sha1), and if the new hash is missing, check the old one, and i it matches
compute the new hash, and store)

It really come down to what's more likely (in order from most to least):
 Someone retrieves a copy of the user's table from the DB server (via a
unpatched bug),
 Someone MITM's your connection (either directly or via dns poisoning),
 The DBA abuses his rights, and misuses the information he has access to.

So I guess (assuming you trust the database and server admin(s)), storing
encrypted unhashed passwords is the preferred method.  If you want to change
the encryption key, you can re-encrypt the entry for each user.

Norman

On 6/13/07, Michał Minicki <martel at post.pl> wrote:
>
> Magnus Henoch <mange at freemail.hu> napisał(a):
>
> > You got it the wrong way.  With encrypted passwords in the database,
> > man-in-the-middle attacks are _more_ likely to give the attacker your
> > password.
>
> Could you explain it in greater detail, please? Imagine two scenarios:
>
> 1. you keep encrypted passwords in a DB and transmit actual password on a
> SSL secured line
> 2. clear text DB passwords and encrypted key transmitted over a SSL
> secured
> wire
>
> Now, we have two different kinds of a man-in-the-middle entities:
>
> A. parties who take part in relying the information (transmission)
> B. Jabber Server system administrators and their system users
>
> To me it seems like scenario 1 is a bit more safe. Both parties, A and B,
> have access only to encrypted passwords. And in order to sniff the
> passwords out, administrator has to inject it's own piece of software in a
> place when the password gets out of SSL and is compared to encrypted or
> hashed DB password.
>
> In scenario 2, party named A has a tough job because the actual
> information
> is encrypted twice (SSL and an actual encrypted password, right?). But
> party A has access to totally unguarded information. It takes only a
> little
> mistake on part of the administrator or a bug in the software itself, to
> let the users get to this information. Not to mention administrator has
> unlimited access to sensitive information without any effort.
>
> Or do I get it totally wrong?
>
> PS: Is it me or is your attitude a little hostile? I'm just trying to
> understand. If it makes you all feel so uneasy, then I will stop writing.
> There's no real sense in such argument - we will be wasting our precious
> time.
>
> > Magnus
>
>
> --
> Martel Valgoerad aka Michal Minicki | martel at aie.pl |
> http://aie.pl/martel.asc
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> "Idleness is not doing nothing. Idleness is being free to do anything."
> -- Floyd Dell
>
> _______________________________________________
> JAdmin mailing list
> JAdmin at jabber.org
> http://mail.jabber.org/mailman/listinfo/jadmin
> FAQ: http://www.jabber.org/about/jadminfaq.shtml
> _______________________________________________
>

-- 
- Norman Rasmussen
- Email: norman at rasmussen.co.za
- Home page: http://norman.rasmussen.co.za/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.jabber.org/pipermail/jadmin/attachments/20070613/02b6afdc/attachment-0001.htm