WebApp Sec mailing list archives
RE: Current Project Design, Comments?
From: Michael Loll <mloll () pointetech com>
Date: Mon, 17 Feb 2003 12:36:55 -0500
I'd be more than happy to explain the authentication mechanism. First, a user with ADMIN rights creates a person's user account. This does the following: 1) Admin enters the new username, 2) Admin enters the new password, 3) Admin confirms password Next, I have a component that creates a random 5 byte value which I convert to standard ASCII text using the BitConvertor.ToString() class/method. I then append this string to the password, so in a sense I did this: 1) Generated salt value S, 2) Appended S to password P ( P' := S + P ) For exmaple, say my password was "12345" and my salt was "fj623" then P' would be "fj62312345". Now, I have a new password string, P'. I then use the SHA1 algorithm on P' to generate a hash of P', called P''. I convert the hash (of type Byte() ) to a string value in Hex format for easy storage in the database (I prefer how Hex *looks*, YMMV). The person's username, P'', and S values get entered into the user table. Now we have a new user account. When the new user logs in, the follow happens: 1) User enters username and password (P), 2) Component retrieves P'' and S from database SELECT P'', S FROM UserAcct WHERE UserName = username; 3) Component takes user-supplied password, we'll call it K, and appends S to it (K' := S + K) 4) Component hashes K' using SHA1 algorithm to produce K'' 5) If K'' = P'' then the user has been authenticated The reason for storing a password hash in the database and not a password is that it prevents a person from gaining acces to the table in some other way (DB exploit or something) and just changing a plain text password entry to something else. This way, even if the person gained access to the table, they would not be able to recreate a usable password without knowing (1) what hashing algorithm we used and (2) how we applied the salt value (did we append it, prepsend it, do some other calculation, etc). RE: Q2 in your email I am aware of FormsAuthentication, but we are not using client-side cookies, which are required of FormsAuthentication (as I recall). Hence we can't use it. If anyone knows if we can use FormsAuthentication without client-side cookies, let me know. RE: Q3 in your email SSL is a must, but we may not use IPSec for Web <-> DB. People have told me it is extremely slow, and the client has said it may not be necessary. Besides, since it is programming-independent you can easily add it later with no programming changes. RE: Q4 from your email I am not concerned so much with DDOS. This is an Intranet application behind a firewall so any DDOS would come from a machine within the network (assuming the firewall isn't broken), and if that happens, well, the client doesn't seem worried. We've discussed how their could be malicious internal users, but we are making an assumption about our users. What is this caching mechanism everyone keeps talking about? -----Original Message----- From: Gal Rozov To: Michael Loll Cc: webappsec () securityfocus com Sent: 2/17/03 4:01 AM Subject: RE: Current Project Design, Comments? Hi Michael, 1. "Client to Web Server: Custom authentication against a username/password stored in Oracle DB. The database actually only stores the username, a hash of the password, and a random salt value used in the hashing process. No password is actually stored in the database." - Can you please explain in more detail how this works?, if you store a hash with random salt how can you compare the hash to the entered password when the user logs in and validate him? 2. ASP.Net has a login mechanism to do the redirection automatically, why haven't you used it or extended it? 3. Have you considered the performance issues of your design, I see you used a lot of security layers that can reflect on the site's performance. Can someone shade a light on this subject from his own tests because I saw some benchmarks from Microsoft yet I'm still not sure they checked all the aspects together? 4. As someone said before you can't rely on the ViewState mechanism because it's not that secure (Base64 with some salt), you can consider using the Caching API for saving data. Depending on your server strength and the size of the data, look for it on MSDN :) * If you use session variables your server is more prone to DDOS attacks because it can crash when the system looses free resources space. (as against to caching API that slows down the server when it happens) All and all it looks great and I'll be glad to get your impressions/conclusions when you finish with the site, we also plan on developing an ASP.Net secured site and it will be great to get some UNBIASED remarks on ASP.Net secured sites :) Thanks and Best Regards. Gal Rozov Senior Developer. Aladdin. Securing the Global Village. P.O. Box 11141, Tel Aviv 61110 Israel Tel: +972 3 636-2222; Fax: +972 3 537-5796 Visit us at our Web site! http://www.eAladdin.com Aladdin supports Idealist. Visit http://www.idealist.org
Current thread:
- Re: Current Project Design, Comments?, (continued)
- Re: Current Project Design, Comments? Kevin Spett (Feb 14)
- RE: Current Project Design, Comments? Brass, Phil (ISS Atlanta) (Feb 14)
- RE: Current Project Design, Comments? Michael Loll (Feb 14)
- RE: Current Project Design, Comments? Michael Loll (Feb 14)
- RE: Current Project Design, Comments? securityarchitect (Feb 14)
- RE: Current Project Design, Comments? Logan F.D. Greenlee (Feb 14)
- RE: Current Project Design, Comments? Michael Loll (Feb 14)
- RE: Current Project Design, Comments? Tim Aranki (Feb 14)
- RE: Current Project Design, Comments? Scott (Feb 14)
- RE: Current Project Design, Comments? Gal Rozov (Feb 17)
- RE: Current Project Design, Comments? Michael Loll (Feb 17)
- RE: Current Project Design, Comments? TUER, DON (Feb 17)
- RE: Current Project Design, Comments? Douglas Schlenker (Feb 17)
- RE: Current Project Design, Comments? Sarbjit Singh Gill (Mar 03)
- RE: Current Project Design, Comments? Vitor Ventura (Mar 18)
- RE: Current Project Design, Comments? alex (Mar 18)