
Pgsodium: Modern cryptography for PostgreSQL using libsodium - sbuttgereit
https://github.com/michelp/pgsodium
======
michelpp
Author here. I'd like to put it out there that pgsodium is relatively new work
that hasn't seen any serious battle testing. At this point you should consider
it more risky to use than pgcrypto, for now.

That being said pgsodium is far less code than pgcrypto, it contains no
algorithms or magic numbers, it's a straight no frills interface to libsodium
which is a very well tested library based on solid cryptography.

Also pgsodium has some features that pgcrypto doesn't have:

    
    
      - Public Key Signatures
      - Anonymous Sealed Boxes
      - Key Derivation Functions
      - Key Exchange
      - Server Managed Secret Keys
    

Feel free to drop me any questions here!

~~~
stblack
This is HN, where commenters liberally espouse variants and competitors.

Props to you, the author of pgSodium, for being the first to mention pgCrypto.

The extra features of PgSodium look handy. Is featureset the main reason you
created PG sodium? Or are there other reasons, like performance, or
interfaces, for example?

New entrant risk aside, are there other reasons to maybe prefer pgCrypto at
the moment?

~~~
michelpp
I wrote pgjwt, a JWT implementation for Postgres, my primary motivation is
that pgcrypto does not have public key signing, which is needed for JWT. Once
I started experimenting with the one feature it sort of snowballed from there,
I still haven't implemented public signing in pgjwt!

To keep using pgcrypto? Well its got a lot of history, so its easy to find
examples of its use. The documentation is decent. And it comes with most cloud
providers where you are generally restricted from installing extensions like
pgsodium.

To not use pgcrypto? I'll use the words of a core PostgreSQL developer said
recently on the pgsql-hackers mailing list:

"I'd strongly advise against having any new infrastructure depend on pgcrypto.
Its code quality imo is well below our standards and contains serious red
flags like very outdated copies of cryptography algorithm implementations. I
think we should consider deprecating and removing it, not expanding its use.
It certainly shouldn't be involved in any potential disk encryption system at
a later stage."

------
Varriount
> In general it is a bad idea to store secrets in the database itself

Perhaps my ignorance is showing but do hashed passwords count as secrets?
Because those are usually stored in databases.

~~~
orev
Properly hashed/salted passwords are considered safe to store in a database.
You still wouldn’t want them to be stolen, but they are not in plaintext.
There are other times when you do need to store secrets that you need to be
able to decrypt so you can use them.

~~~
ithkuil
It all depends on two factors:

a) minimal required entropy of the passwords themselves.

b) how computation expensive is the hash function itself.

The threat model in password bashing scenario is that the attacker wants to
discover the password and then use it to impersonate the user.

Thus the attacker needs to guess the password, by searching though the space
of all possible passwords (using heuristics such as dictionary, common
letter/number replacements, common position of symbols mandatory in many
password policies) and the the candidate password needs to be hashed and
compared to the known good hash.

By using an expensive hash function such as bcrypt you can limit the ability
of exhaustively search the space of all possible passwords. But if a user uses
a weak password, the attack will succeed and leaking the hashes will make the
search go several orders of magnitude faster than online brute forcing (I.e
real login attempts, which can be throttled)

~~~
e12e
c) the fact that in the real world, some users will re-use "secure" passwords.

~~~
ithkuil
In the real world this reduces password entropy, thus it falls under (a) :-)

EDIT: perhaps it would be easier to just think of it in terms of
predictability. Often tech jargon gets in the way.

~~~
e12e
Yes and no. You could argue the infamous Debian openssl bug reduced entropy
[1], but it really is about compromised keys. Or in this case compromised
passwords.

[1] in a sense, this is of course obviously and literally true (that it is
about entropy). But I think the more interesting distinction is between leaked
secrets, and "bad" secrets - in that light the "Debian keys" all form a group
of "leaked" secret keys. There's nothing inherently wrong with the generated
keys - but you'd have to improbably unlucky to "accidentally" generate any
given compromised key using a good rng. In the same way, the password "T
_GSCfkL$seG2@tn5D_ owiFJ$nPj%KW#vMT" that bitwarden just generated for me
isn't inherently bad - until now, that it's been published/leaked.

So I'm not sure I agree that it's all/only about entropy.

I think it illustrates well that secrets and especially those managed by
people (such as passwords and passphrases) have systemic component: the system
seen as a whole incorporates users, other systems as well as any one given
system (Gmail is affected by leaked Hotmail accounts, and vice-versa).

~~~
ithkuil
I'm not disagreeing.

I just wanted to highlight to to break a password you need a) to guess it b)
to verify it.

Leaking the hashes affects (b)

