storing passwords
Andrew MacIntyre
andymac at bullseye.apana.org.au
Mon Jan 15 16:10:29 EST 2001
On Mon, 15 Jan 2001, Neil Schemenauer wrote:
> On Mon, Jan 15, 2001 at 10:08:52PM +0200, Moshe Zadka wrote:
> > On Mon, 15 Jan 2001 Andrew MacIntyre <andymac at bullseye.apana.org.au> wrote:
> >
> > > I wrote a simple module that stores the account,password pair as an XOR
> > > "masked" string in a dbm file with the hostname as the key. The module is
> > > only published (put in the PYTHONPATH) as a .pyc/.pyo, so the full source
> > > is not generally readable.
> > >
> > > This is only obscurity however, not real security.
> >
> > And not even good obscurity! .pyc files are actually quite readable
> > if you use the dis module, and I think Mr. Aycock wrote a decompyler.
> > Don't use security through obscurity, please!
>
> There's no excuse either:
>
> import sha
> def hash_password(password):
> """Apply a one way hash function to the users password and
> return the result"""
> return sha.new(password).hexdigest()
>
> def valid_password(self, password, hash):
> "Return true if the provided password is correct"
> return (hash == hash_password(password))
>
> Its easy to add some "salt" to the hash too if your worried about
> dictionary based attacks.
In the application I had, I needed the password in raw form (it was for an
account on a different system) so a hash was no good.
Everything that has been said about security vs obsurity I agree with, but
sometimes circumstances force you to take an approach you'd rather not.
In the particular circumstances at the time, the risk assessment was that
the solution I used was tolerable in view of there being no alternative
solution (organisational politics were the difficulty, not
technicalities).
--
Andrew I MacIntyre "These thoughts are mine alone..."
E-mail: andrew.macintyre at aba.gov.au (work) | Snail: PO Box 370
andymac at bullseye.apana.org.au (play) | Belconnen ACT 2616
andymac at pcug.org.au (play2) | Australia
More information about the Python-list
mailing list