web-security methods, advice please!

[Lennart Sorensen]

On Tue, Jan 02, 2007 at 11:51:27AM -0500, Madison Kelly wrote:
> Lennart Sorensen wrote:
> >>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.
> 
> The idea, as I understood it, was to force a brute-force attach to try 
> X-number of hashes per password, slowing down a brute-force attack to 
> about 1 password/second. It may be overkill though, specially because of 
> the server-side CPU resources required...
> 
> >>- 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.
> 
> If you were on a website that was storing your personal info (ie: 
> financial data, CC numbers, etc) would it not be worth having to log 
> back in after a dropped connection for the extra security? How do banks 
> handle this? (I don't use web banking). Would there be an alternative 
> string I could/should use that would be hard for a cracker to duplicate? 
> I worry about just using the UA because it is so easily spoofed.

When using https I would think my valid session cookie should be
sufficient.  There are also some people who have multiple active IPs
through load balancing (although not very common) where two http
requests may come from different source IPs.  I am not convinced
requireing the IP to stay the same adds much if anything to security,
but I am convinced that for a few people it will cause problems.

> MD5 and SHA1 have been compromised.
> 
> http://en.wikipedia.org/wiki/Md5
> 
> "In 1996, a flaw was found with the design of MD5; while it was not a 
> clearly fatal weakness, cryptographers began to recommend using other 
> algorithms, such as SHA-1. In 2004, more serious flaws were discovered 
> making further use of the algorithm for security purposes questionable."
> 
> http://en.wikipedia.org/wiki/SHA
> 
> "It [SHA1] was considered to be the successor to MD5, an earlier, 
> widely-used hash function. Both are reportedly compromised.
>
> The other four variants (SHA-224, SHA-256, SHA-384, and SHA-512) are 
> sometimes collectively referred to as SHA-2 functions or simply SHA-2. 
> No attacks have yet been reported on the SHA-2 variants, but since they 
> are similar to SHA-1, researchers are worried, and are developing 
> candidates for a new, better hashing standard"
> 
> *nix systems that use '/etc/shadow' use a random 2-byte salt and add it 
> to the user's password when (re)set before the hash is generated. Then 
> the salt is thrown away. When a user tries to login, their password is 
> run through (up to) 4096 combinations until either the proper hash is 
> matched of the number of possible salts run out and the password the 
> user supplied was deemed to be wrong. This slows down a brute-force 
> attack a bit, but not much. So a person wanting to crack into a *nix 
> system (assuming they have access to the password hashes from 
> '/etc/shadow') wouldn't need to try very hard with an MD5 rainbow table 
> if the user's password was otherwise weak.

I believe with MD5 passwords, the salt is much larger, and is kept in
the password file.  With the larger salt, generating a precalculated
lookup table with become very very large and time consuming, while
reducing the time to check the password under normal use.

> This is why I didn't want to duplicate the *nix shadow file method. It's 
> not very secure anymore.

Well if the user password is weak, it probably still won't take very
many tries to break it no matter what you do.

> I do agree though that using my own code isn't ideal, for exactly the 
> reasons you mentioned. Perhaps there is some more tested canned code I 
> could use?

Well you could always use SHA-512, since at least no one has broken it
yet, and people have tried.  Writing your own you just risk making one
that isn't secure but you don't know it because no one has really looked
at it.  I certainly won't try inventing my own password hashing method.
Just look at GSM, WEP, windows passwords, and many others for examples
of what happens when people try to invent encryption systems without
knowing what they are doing.

--
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