On Tue, Jun 02, 2009 at 11:04:05PM -0700, Roger Binns scratched on the wall:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Sambasivarao Vemula wrote:
> > I want to encrypt a perticular field in sqlite3 database.
>
> You can use the SQLite Encryption Extension which will encrypt the whole
> database. This is by far the easiest approach and you won't have to
> worry about accidentally encrypting some fields and not others. After
> all if you are storing some valuable information, how do you know the
> rest won't be valuable either?
>
> http://www.hwaci.com/sw/sqlite/see.html
>
> > I want encrypt a password field in a table
> Encrypting the password is a very poor approach to password security.
Depends on what you're after. There are good reasons to store
passwords in a recoverable format.
> Best practise is to store a one way hash of the password. A one way
> hash is a checksum of the data that is computationally infeasible to
> recover the original data from. Two example hashes are md5 and sha1.
But, as you pointed out later in your message, in today's world of
multi-GHz, multi-core machines, the hash of something as small and
simple as a password is brute-force crackable by most people in a
reasonable time period (a few months). This is something a stronger
hash cannot protect against... the password search space just isn't
that large.
So in today's world you pretty much have to assume that if someone
has your password database-- no matter how it is encoded (encryption
or hash)-- you're screwed and you've already lost.
The big disadvantage of hash systems is that the during the
authentication process you need to get the password from the user
to the hash database in a recoverable format, which is more or
less a fancy way of saying "in the clear." It might be hidden inside
a encrypted channel of some sort, but the password must be
recoverable.
And that's the whole problem: If you store passwords using some kind
of one-way transformation, you need to transmit them in a recoverable
format. This allows the hash to be done on the database side and a
comparison done. The hash must be done on the database side or
you're open to replay attacks.
If you want to transmit the passwords in a non-recoverable format
(e.g. after a one-way transformation such as a hash) you need to
store the passwords in a recoverable format. The hash can be done
client side using a random server provided salt (important), but
the database has to have an original password to generate a comparison
hash.
It is very much a "Damned if you do, Damned if you don't" kind of
thing. In general I'd go with a hashed database and in-the-clear
transmission, but only if I'm operating in an HTTPS or some similar
encrypted channel (where someone else wrote the channel encryption!).
Hashing on the client side assumes we "own" the client, but also lets
a cracker run test values through the hash algorithm. If they sniff
a hash and know our hash algorithm, they can off-line brute force the
system. So, ideally, even hashed passwords need to be encrypted
during transport.
That said, getting anywhere with a "transmit hashed, store
recoverable" system it is a fair amount of work, and for a
simple system that is otherwise unencrypted, it is a fair approach.
Clearly a "transmit recoverable, store hashed" system has a huge
dependency on a solid channel encryption.
Without an encrypted transport you're technically open either way.
The question is mostly how much you want to make them work for it,
and how secure you think you can keep your server.
The only way you can keep a password unrecoverable all the time-- both
in the database as well as during transmission-- is using a public
key/private key system. That takes some serious understanding and is
very easy to get wrong, even if you're using a library for an
existing algorithm.
As you said, security is very *very* hard. Many people have a hard
time thinking like an attacker and it only takes one minor screw-up
in the code or design for everything to fall apart.
-j
--
Jay A. Kreibich < J A Y @ K R E I B I.C H >
"Our opponent is an alien starship packed with atomic bombs. We have
a protractor." "I'll go home and see if I can scrounge up a ruler
and a piece of string." --from Anathem by Neal Stephenson
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
