RE: Current Project Design, Comments?

[Michael Loll <mloll () pointetech com>]

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