15 Responses to “Preparing a secure login form with PHP & JavaScript”

  1. Ryan Says:

    That does not seem like a lot of code. Will test this out.

  2. Ashish Anand Says:

    First of all!!! Great!! 🙂

    Can you extend this further so that it can be implemented for registration page too!! In case of registration page, if i go for the same technique and a sniffer sniffs out the password hash, everything else would then be rendered stale, beacuse the sniffer has the original password now!!!!

    Can we make it work for registration too???

  3. krahulg Says:

    This is definitely not for registration since this will only work if the password is known at both ends beforehand. For Signup pages, you can use any of the available encryption methods but please do check up the legal implications before finalizing on any particular encryption procedure.

  4. William E. T. Says:

    Its a really bad idea to store unhashed passwords in a database. If that database gets compromised (even if its read only access) then the compromiser will know everyone passwords. An obvious example of why this is bad is most people re-use passwords, but I don’t feel like making a formal argument, so just google and you’ll find why you should only be storing hashed passwords.

  5. krahulg Says:

    Very true William. And I will add a UPDATE to the post because it struck me later on that some people might lap it up as it is presented.

  6. Gabriel Says:

    I resolved the hashed password issue. My database actually stores MD5’ed passwords. Here is how I did:
    The javascript calculates the password’s MD5. Then it concatenates the result with the timestamp and calculates the MD5 again. The result is sent to the server.
    The server reads the MD5’ed password from the database, concatenates the timestamp and calculates the MD5.
    Now compare the received hash with the calculated one and here you are!

    I guess all this MD5 thing is a simple way not to send plain text passwords over the web, but it still is quite vulnerable. A clever eavesdrop reading the POST request can figure out how all this is done and, later, try to obtain the hashed password with a bruteforce loop:

    1. a = string to test
    2. a += timestamp given in the POST
    3. b = MD5(a)
    4. if (b == password given in the POST) { bingo! }
    5. goto 1

    I guess some days or weeks would be enough to break the password, probably less with a dictionary-based loop first.

  7. Gabriel Says:

    Ops, I did not thank you for the idea! I just implemented it and feel a deep relief not to sent plain text passwords anymore.
    Thanks (:

  8. krahulg Says:

    Hi Gabriel, and am really happy to see you taking attention and even going as far as adopting it.
    About security, well, I have given up on the idea of a future-proof security device or method. The best I can do is make a parrot learn vowels and pass messages through it. How would you know which parrot to trap?? “Don’t get anybody curious” might be the way to it, but I have other things to do right now. :).

  9. […] No Translations This article discusses a way for HTML login forms not to transmit plain-text passwords over the internet when SSL or https are too complex and still in your TODO list. This is an enhancement of this solution. […]

  10. vijay Says:


    Thanks again for the info shared.

    I fell a “BIG” thing is missing here.
    What if the sniffer sends $hts greater than the current time. he will be successful in logging into the system.

    may be u have that in ur mind but dint tell it out..
    ” system described here lacks certain things which are very obvious”

    Thanks for letting me know .. if I got it completely wrong !

  11. krahulg Says:

    Hi vijay,
    you can always send the hashing timestamp greater than the current time, but remember that you also have to hash the password with the timestamp. for the attack to succeed you need to know the password and hash it correctly. if you know the password already, you would rather use the login form and then nothing can stop you. am i right in getting your point here??

  12. vijay Says:

    Thanks Rahul,
    You are correct and I am such a jerk ! 😦

  13. paul Says:

    I really like the idea. However one would have to combine it with HTTPS (preferably with a certificate signed by a well-known and trusted entity) to prevent a possible man-in-the-middle attack.

    Otherwise the man-in-the-middle could just remove the java-script code and then do the hashing before sending the request on to the real server.

    But then again, when using HTTPS with a trusted certificate, is there really any need to send a hashcode instead of the verbatim-but-now-SSL-encrypted password?


    And I see another possible problem: what about overly-restrictive content-filters that strip java-script? A page crippled by such filters would still send the password in cleartext. The server could of course recognize such a case by inspecting the “password” and “phash” fields, but the password would still be on the wire in cleartext.

  14. krahulg Says:

    @paul: I had put this up as an alternative to simple login systems, the based ones. This definitely is not a replacement for HTTPS. And the setup required to really do a man-in-the-middle against this is fairly demanding and simple listening won’t do.
    And thanks for stopping by, its very lonely out here.

  15. […] ‚Preparing a secure login form with PHP & JavaScript‘ by Kumar Rahul (observances): Beschreibt die Clientseitige Verschlüsselung des Passwortes mit MD5 (SHA-1 wäre auch möglich), „gesalzen“ mit einem Timestamp aus PHP::time() […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: