can someone encrypt for me??

thanks before

********** Error **********

ERROR: syntax error at or near “,”
SQL state: 42601
Character: 1404

On the other point, if I crack your web server, I have database privileges as the web user account. That should leave you only partially screwed since the web server connects as an unprivileged user. It takes a whole other level of kung-fu to get to super user from there. And it takes a while.

Anyway, not throwing rocks, this is an excellent intro to pgcrypto and custom operators. Thanks!

To get hashes bad guy would have to have database privileges, and in this situation we’re screwed anyway. The point is that he/she will not be able to get the passwords to use them someplace else.

Doesn’t this negate the whole thing? I thought the purpose was to make the hashed values useless to a bad guy. This makes them identical in function to the real passwords.

However, I would like to add that if there is a legal requirement that you not store plaintext passwords, be very careful that no SQL statements get logged, and that no monitoring scripts watch pg_stat_activity. Otherwise a password might get saved in plaintext in a log or notification.

Oh, I see. Makes sense, particularly the point about backups.

of course hacker that will hack, get root access will be able to circumvent it, but it will take longer time, thus it makes the hack easier to be revealed.

also – sometimes password encryption/hashing in database is external requirement (think: business, local law, common practice)

If you’re not protecting against the DBA, then why not just REVOKE and forget encryption all together?

If the goal is to avoid accidentally storing the plaintext password (as DBA), I showed two examples where it’s easy to accidentally store the password in plaintext if you’re the DBA.

For instance:
* anything that causes the statement to be logged, such as log_min_duration_statement
* anyone who has access to pg_stat_activity. You might have monitoring scripts that show you some query worth looking at, and that query might end up being the one to insert the password.

And probably some other stuff. It is certainly worth considering to keep all encryption _outside_ of the database. You can’t keep information secure from the DBA if it’s encrypted by the database. And if not keeping it secure from the DBA, why not just revoke privileges from everyone else?

@Andrew Hammond:
i really think md5 is sufficient for passwords. using sha* is good for cryptographically secure document signatures, but for password – i don’t see real need to use anything > md5.

@smk:
sure, you’re right.

@Ron:
take a look at trigger code – salt *is* random.
gen_salt() function generates random salt.

My worry about the solution discussed above is that it’s using md5 instead of the more robust / security-droid compliant sha512. Fortunately that’s easily fixed:

SELECT encode(digest(decode(TEXT ‘swordfish’, TEXT ‘escape’), TEXT ‘sha512′),
TEXT ‘base64′);

Or you can skip that outer layer of encoding and handle passwords as bytea. Annoyingly, this requires having built against openssl 0.9.8+.

A solution which avoids these pitfalls is to use the database connection as the authorization function in your application. The downsize for that is that each user must use a separate connection which for HTTP means each GET/POST will create a new connection (connection pooling tends not to be useful as it is unlikely that a user will be serviced by the same process).

Nevertheless, in many cases, especially for intranet applications for small and medium sized offices, the performance hit is negligible and the improved security and data access is well worth using the database authorization system.