Very Computer

I have seen in many instances where website customers passwords are stored
in databases like Oracle. What is a safer way to store passwords in
databases? If a hacker breaks in to the databases he has access to all the
passwords.

Also people who use php or asp or perl scripts have passwords in their
scripts for the database connections. If a hacker breaks in and sees these
scripts he can easily find that login and password.

If you're using Perl, there's a whole stack of Perl modules that do a nifty
bit of encryption.  Beowulf, Blowfish, DES, RSA, TripleDES, etc...

http://www.cpan.org/modules/00modlist.long.html

Check under the Crypt:: heading.

.lo-tek.

Quote:> I have seen in many instances where website customers passwords are stored
> in databases like Oracle. What is a safer way to store passwords in
> databases? If a hacker breaks in to the databases he has access to all the
> passwords.

> Also people who use php or asp or perl scripts have passwords in their
> scripts for the database connections. If a hacker breaks in and sees these
> scripts he can easily find that login and password.

I think Philip was referring to the password to access the database, not
any passwords stored within the database...

--
Christer Palm

No he's not. He's referring to things like: passwords for access to web-
based services. They're usually stored in the clear inside the DB, since
the web developers don't know what they're doing.

At the very least, the following should be done: (1) For each user listed
in the DB, store a large random integer in a field called "salt". (2) The
passward is concatenated with the salt, and then a hash is taken. For
example, MD5 or SHA. (3) The hash is stored in the "password" field.

To perform authentication, take the user-supplied password, concatenate it
with the locally stored hash, and compare with the value stored in the DB.

This is a major security concern, not only because of the risk of one site
being compromised, but because people reuse passwords. For the people who
are compromised in this way, NONE of their accounts should be considered
safe. So the site maintainer is guilty of a major breach of privacy against
his own users.

--Len.

--
Early to bed and early to rise makes a man tired and grumpy.
                                -- Dan Bernstein

Well, if you are using Challenge-Response Authentication then you need to
store the password in clear.

Quote:> being compromised, but because people reuse passwords. For the people who
> are compromised in this way, NONE of their accounts should be considered
> safe. So the site maintainer is guilty of a major breach of privacy against
> his own users.

Of course using hashed passwords does not mean an intrder cannot insall a
trojan, so using secure passwords is not as important as one might think.
Especially since the DB can be protected independendly from the Web
Application and the tool verifying the passwords does not need to hand them
out

Greetings
Bernd

Actually, he's referring to both.
I didn't properly read his first sentence - my mistake, but in the
second, he clearly refers to the password used to access the database.

--
Christer Palm

That's incorrect. See <http://www-cs-students.stanford.edu/~tjw/srp/>.

It's also very, very wrong. Storing passwords in the clear should NEVER
be done by a server under ANY circumstances, PERIOD. One reason I already
gave: users reuse passwords. If you store a person's password, and it
happens to be the same as his Net Banking password, YOU share culpability
for misuse of that information resulting from compromise of your security.

Another reason is that it's stupid: one successful crack compromises ALL
user accounts.

Another is that storing passwords in the clear means that YOUR employees
can impersonate your customers. Since the majority of security breaches are
actually due to disgruntled employees, this is a serious issue.

--Len.

--
Frugal Tip #29:
Every other day put your shoes on the wrong feet so that they wear
more evenly.

The problem here is, that SRPs "non-plaintext-equivalent" does not work for
other protocols, which are most likely to be used (also those are much
wealer they are much wider implemented (CHAP, APOP, ..)

Greetings
Bernd

Since the original question was about how to store passwords, apparently
the poster has a choice. In that case, plaintext passwords should NEVER
be stored. If the protocol mandates it, then a different protocol should
be chosen.

--Len.

--
Frugal Tip #26:
Hang around with that Donald Trump guy for a while. He's probably good
for a couple of ideas.

So what if I don't want to use this

Quote:> It's also very, very wrong. Storing passwords in the clear should NEVER
> be done by a server under ANY circumstances, PERIOD. One reason I already
> gave: users reuse passwords. If you store a person's password, and it
> happens to be the same as his Net Banking password, YOU share culpability
> for misuse of that information resulting from compromise of your security.

Is that your opinion as a lawyer based on cases or your opinion as a
security expert. Or indeed just a m*statement.

Quote:

> Another reason is that it's stupid: one successful crack compromises ALL
> user accounts.

Agreed.

--
Niall Litchfield
Oracle DBA
Audit Commission UK

Come again?

.lo-tek.