Re: Salt in encrypted password in pg_shadow

From: Mike Nolan <nolan(at)gw(dot)tssi(dot)com>
To: tgl(at)sss(dot)pgh(dot)pa(dot)us (Tom Lane)
Cc: steve(at)blighty(dot)com (Steve Atkins), pgsql-general(at)postgresql(dot)org
Subject: Re: Salt in encrypted password in pg_shadow
Date: 2004-09-08 04:59:24
Message-ID: 200409080459.i884xPau029234@gw.tssi.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

> So as soon as someone wheels up a new crypto hash method that looks
> trustworthy, we can invent a new auth protocol and maybe throw in
> another level of random salting while we're at it. But right now
> I doubt it's worth the effort :-(

A relatively simple enhancement would be to use some or all of the user
name as the salt. That makes reverse engineering the passwords a bit
harder because there are multiple salts being used.

I suspect that with the speed of modern microprocessors that nearly any
crypto scheme is breakable using a few thousand dollars worth of hardware
and a few hours of time. If the NSA has built in shortcuts to their
sanctioned algorithms, that just makes the cracking process faster.

I know of an ecryption technique developed by a friend of mine, a retired
mathematician, that would probably be sufficiently robust. It uses group
theory to permutate the bit field and has both reversible and
non-reversible forms.

It would probably be subject to export restrictions. As I recall, he
couldn't even send a copy of the program to his son in Greece without
State Department approval.

But as long as people use vulnerable passwords, there is no password
encryption scheme that isn't vulnerable to attack, with or without
salt.

Challenge/response and one-time password schemes are more secure but
a lot more hassle for users.
--
Mike Nolan

In response to

Browse pgsql-general by date

  From Date Subject
Next Message David Garamond 2004-09-08 05:59:17 Re: Salt in encrypted password in pg_shadow
Previous Message Randy Yates 2004-09-08 04:43:07 Re: Another Security Question: User-based Roles vs. Application