| Subject: | libcgi-session-auth-dbi-perl: Room for improved security. |
| Date: | Fri, 06 May 2011 00:11:10 -0500 |
| To: | bug-CGI-Session-Auth [...] rt.cpan.org |
| From: | Mike Mestnik <cheako [...] mikemestnik.net> |
Version: DBI.pm 25 2006-02-21 12:07:26Z geewiz
There are 6 bugs here, feel free to clone this or ignore some of
these... Just not the bug I'm reporting,
The really really really important part, line 106 should be moved down
at least 6 lines. The password should not be going anywhere until after
it's hashed. Any logs made as a result of this statement would result
in the generation of a lookup table matching passwords to hash though
user-names to passwords is more accurate.
Let me try and be clear on this. The idea of hashing all the passwords
is to protect the passwords from any one and every one(including and
especially the administrators/owners/operators) who may have access to
the stored passwords. It's not likely the stored passwords will be kept
in a place less secure then any logs and it's considerably impossible to
imagine that crypted passwords would be readable by anyone who would be
unable to read the logs and/or activate debugging to create logs.
Though it's true every application has a week spot where it's data can
be shunted out a backdoor some where, it's not something that should be
readily accessible.
The purpose being so that users can albeit not safely use the same
password to multiple resources without the fear that one admin will use
this to gain access to a resource he/she is not entitled. An example
being A Yahoo mail user using the same password for a Google Account of
some sort, could be Gmail or something else. One day as Yahoo goes out
of business they may try there extensive password database against
Google accounts to see what's what. Nothing could prevent this, but a
good step is to ensure that every or at least as many password database
are unusable to any one who may or may not have malicious intent.
EncryptPW is not documented.
HashPW should be an alias to EncryptPW because [1]md5, the cryptographic
hash function, is not Encrypt(ion).
CryptPW could also be an alias, though you need to support a lot
MORE(DES, MD5, Blowfish, SHA-256, SHA-512, ect) then md5 to be
considered a replacement for crypt(). Neither of these functions have
much if anything to do with Encryption, though the term
One-Way-Encryption was used prior to these functions being named hash
functions.
1. http://en.wikipedia.org/wiki/MD5
I say this mainly because MD5 has been made unusable, SHA1 is even
becoming less usefull. SHA-256 with support for SHA-512 is where most
new deployments and applications should be pointed.
The default passwordfield for hashed passwords should be changed, this
is to avoid the types of problems typically corrected by "strict vars".
On another note:
Postgresql has support for a UUID type, detection of this would be great
for the userid field. The semantics are simple (Input)INSERT and UPDATE
as you do now is transparently supported, though (Output)SELECT is
always in the standard form. eg: a0eebc99-9c0b-4ef8-bb6d-6bb9bd380a11
It should only take a small bit of code to support this, like s/-//g.
-- System Information:
Debian Release: 6.0.1
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.35.4-rscloud (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Versions of packages libcgi-session-perl depends on:
ii perl 5.10.1-17 Larry Wall's Practical
Extraction
Versions of packages libcgi-session-perl recommends:
ii libdbi-perl 1.612-1 Perl Database Interface (DBI)
libcgi-session-perl suggests no packages.
-- no debconf information