SitePoint Sponsor

User Tag List

Results 1 to 11 of 11
  1. #1
    SitePoint Enthusiast
    Join Date
    May 2006
    Posts
    89
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Securing login forms using javascript

    Now this is for use on a community website, and it's just an extra safeguard, so please don't suggest SSL or something similar.

    My db layout:
    user_id
    username
    password
    salt

    DB password is created by : sha1(sha1($plaintext_password) . $salt . 'secret') at signup.

    I want my client side login form to submit an encrypted version of the form password value. I'm using this javascript function for that: http://pajhome.org.uk/crypt/md5/sha1src.html

    Anyway, if you just submit an sha1() version of the plaintext version to the server, that's no good, since an attacker can just do the same.

    We need to have a salt together with the password so that the value changes every time and the attacker can't do a replay attack.

    So create a $_SESSION['login_salt'] = //random string func();

    However, I can't do: hex_sha1(hex_sha1(form.password.value) + my_session_salt); since I can't compare the client input on the server side with the db password (my db password is not plaintext, which would be needed to compare in this way)

    Does anyone else have any ideas on how to solve this then;

    I'm thinking maybe instead of a server salt ($_SESSION['login_salt']);

    you could have : $_SESSION['login_salt'] = '2f,352:10';

    which would mean: replace all '2' chars by 'f', and add "352" from position 10 in the string. Obviously all those parts would be randomly server generated on each visit. Since the attacker doesn't have the same session salt, if he replayed the attack it would not let him in the system.

    Now I'm not really a 'cryptologist' or whatever you call it so I don't know if this is safe at all.

    Has anybody implemented such a system and what did you do?

  2. #2
    SitePoint Wizard silver trophy
    Join Date
    Mar 2006
    Posts
    6,132
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    hmm i did something like this with md5 once, lemme see if i still have the code archived.

  3. #3
    SitePoint Wizard silver trophy
    Join Date
    Mar 2006
    Posts
    6,132
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    i just reread your post and realized i misread it.
    i cant think of a solution.

    basically your concerned with possibly someone intercepting the data between the client and your webserver.

    as far using an algorithm like 2f,352:10

    maybe i dont understand, but if you dont want the password sent as plaintext, then you need to feed this 2f,352:10 to the client, so javascript could encode the password with it and then send it back. but if they intercept the data coming to the user, and they intercept the data coming from the user, they can still figure it out, because your algorithm is available to them in the javascript code. they can just use the 2f,352:10 to reverse the encrypted password. it would work only if you knew the attacker could not get a hold of the current 2f,352:10 routine.

  4. #4
    SitePoint Guru dbevfat's Avatar
    Join Date
    Dec 2004
    Location
    ljubljana, slovenia
    Posts
    684
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I think you should take a look at Challenge-response authentication. Also, performing a sha1 (or any hashing method) on the same data twice (or more) is useless - it doesn't improve strength of the hashed data in any way.

  5. #5
    SitePoint Enthusiast
    Join Date
    May 2006
    Posts
    89
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Dbevfat, that is exactly what I want but has the same issues as my original post; it requires that you save the password in your db without salting it.

    (I do sha1($password . $randomsalt) and save this in the db on signup)

    I would have to expose the salt on login for that code to work..

  6. #6
    SitePoint Wizard bronze trophy Immerse's Avatar
    Join Date
    Mar 2006
    Location
    Netherlands
    Posts
    1,661
    Mentioned
    7 Post(s)
    Tagged
    1 Thread(s)
    I once coded up something similar that used a one-time salt per session. This salt is then also passed to the login page, and used in the sha1 encryption. I figured it would be safer as each salt was only used once. I'm not too sure anymore, and decided to drop it.

    I think that if someone wants extra security, they should use SSL
    (Pity it can be so expensive though...)

  7. #7
    SitePoint Guru dbevfat's Avatar
    Join Date
    Dec 2004
    Location
    ljubljana, slovenia
    Posts
    684
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Since you're not gonna use SSL, then maybe you're better off exposing the salt (as oposed to allowing random people to sniff plain text passwords).

  8. #8
    SitePoint Wizard bronze trophy Immerse's Avatar
    Join Date
    Mar 2006
    Location
    Netherlands
    Posts
    1,661
    Mentioned
    7 Post(s)
    Tagged
    1 Thread(s)
    True.

    Don't forget NOT to send the password after its been hashed

  9. #9
    SitePoint Enthusiast
    Join Date
    May 2006
    Posts
    89
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Well, the salt is different for each user, so it's kinda impossible to expose it on the login page.. (Since you don't know who the user is yet)

  10. #10
    SitePoint Guru dbevfat's Avatar
    Join Date
    Dec 2004
    Location
    ljubljana, slovenia
    Posts
    684
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    It's indirectly exposed, since it has to be properly calculated to hash the password. But I don't think this isn't a big security problem, looking from the right perspective: it allows you not to send a plain-text password and you still have the password hashed in db. Speaking of which, you may want to use SHA256 rather than SHA1, it's more secure.

    Don't worry too much about exposing the algorithm, after all, even algorithm for hashing linux passwords is "open-source", but this in itself isn't insecure.

    regards

  11. #11
    SitePoint Enthusiast
    Join Date
    May 2006
    Posts
    89
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    It's only exposed after the user has entered his username and I can look the hash up, which is after he/she has already submitted the form.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •