web-security methods, advice please!

[Lennart Sorensen]

On Sun, Dec 31, 2006 at 07:53:42PM -0500, Madison Kelly wrote:
> Hi all,
> 
>   I asked this earlier on TPM who've provided some great feedback. Now 
> I though I'd like to get feedback from the (more diverse) TLUG peoples. :)
> 
>   (Perl) Code below.
> 
>   I've started a web-based CRM program for my new company and so I am 
> more concerned with security than I have needed to be in the past. I was 
> hoping to run down my current plan to see what TLUG'ers think.
> 
>   I am not a cryptologist (or particularly good at math) and make no 
> claims to be a security expert of any kind. So please be brutal and 
> honest with my plans (a cracker would)! :)
> 
> - Two steps; 1. password authentication and 2. Cookie sessions.
> 
> Password;
> 
> - When a user creates (or changes) their password, they send to the 
> server their desired password.
>   - Being a new password, I generate a 36 byte 'salt' string and store 
> this string in the database.
>   - I run their password through SHA256 to get an unpadded base64 hash
>   - I stick the salt onto this initial hash which I call my 'weak_key'.
>   - I then generate a new (base64 SHA256) hash which I call the 'weak_hash'
>   - I take this 'weak_hash', prefix the salt string and generate a new 
> SHA256 base64 hash. I repeat this step 40,000+ times on my old laptop 
> (will do it more on the server when I am done). (reasoning behind this 
> step here: http://en.wikipedia.org/wiki/Key_strengthening ).

Whatever is the point of all the repeated work?  If the hash is any
good, doing it once is sufficient.

> - When a user logs in later their password is again sent to the server.
>   - This time though the salt string is read from the DB and then all 
> the steps above are repeated to see if the same hash value is created.
> 
> Cookie;
> 
> - Once a user successfully logs in, I set a cookie with their user ID 
> number and a session hash.
>   - To create this session hash I create a random number and store it 
> in the database. I look at the current date on the server and then I 
> combine: [UID + Random # + Date + Client UA + Client IP Address] and 
> create a simple SHA256 base64 hash.
> 
> - After this, each time the user calls the program, I:
>   - Read their UA string and their IP address.

I recommend NOT including the users IP in the check.  IP addresses can
change often, even during a session for perfectly good reasons.  If I
was on dial up and my connection died and I reconnect and get a new IP
form the provider, that is not a good reason for any sessions to stop
working.

>   - Get the random number out of the DB.
>   - Check the current and previous date from the server.
>   - Read the UID and session hash from the client's cookie.
>   - Generate two hashes like I did above (one or today and yesterday's 
> date) and check to see if either match the session hash. If so, the 
> session is valid. If the previous date's hash matched, I update the 
> session hash (to account for people working over midnight server-time).
> 
> 
>   The salt string is a 36-byte string of alternating non-alphanumberic 
> characters -> digits -> mixed-case letters. The salt is changed whenever 
> the password is (re)set.
> 
>   I plan to use SSL to prevent sniffing but I don't know enough about 
> cross-site scripting attacks to know how to properly defend against them.
> 
>   Below is the test program I wrote for generating the password hash. I 
> am still working on the cookie code so I can't post that yet.
> 
> Again, *Please* be brutal on your critiques of my methods. If my 
> thinking is flawed, I would be grateful to learn now rather than later. :)
> 
>   Also, I don't believe in security through obscurity in the slightest, 
> so if my methods can't survive being exposed, I'd also rather know now. :)

So why not simply use the same password storage hash system as your
system uses (I believe MD5 hashed passwords are the most commen since
the old unix crypt was limited to 8 character passwords)?  There already
exists code for it, and if it is considered secure enough to encrypt
your root password on the server, you would think it is good for the
password storage of your web page users too.  Why reinvent the wheel and
use code that no one else does, meaning code that no one else will check
for bugs and maintain.

--
Len Sorensen
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists