3

I'm creating a web application that requires an authentication process. Saddly, I can't use HTTPS, so I'm stuck with the insecure HTTP. Currently, I'm sending passwords in plain text through HTTP... I know it's bad (even with HTTPS)! That's why I search a way to hash the password in JS, and send the hash to the server. Do you guys have any idea how i could do that ? (using the same blowfish implementation as PHP would be the best solution according to my needs)

Thanks !

edit : I know that anybody that could intercept the string could connect, but they couldn't know the password, only the hash.

Ragagno
  • 53
  • 1
  • 5
  • 8
    If you can't use HTTPS, you won't have a secure website. – Pointy May 10 '17 at 12:27
  • https://gist.github.com/jo/8619441 may be a starting point – Jonas Wilms May 10 '17 at 12:28
  • 5
    And how would this be any more secure than sending the plain text password? Anybody who intercepts it still has exactly the string they need to authenticate. – David May 10 '17 at 12:28
  • 6
    Also *everybody* can use HTTPS. There are no good reasons not to use that here in 2017. – Pointy May 10 '17 at 12:28
  • Well there's javascript-blowfish (https://github.com/agorlov/javascript-blowfish). You could encrypt the password upon registration, then send it, then encrypt that once again on the server side. This will lead to an obvious problem when logging in. So when logging in, you could again encrypt it, send it on the server side and process it in the same way. Is that what you're asking? – Vergil Penkov May 10 '17 at 12:29
  • I think this library will help you: http://stackoverflow.com/questions/17685645/rsa-encryption-javascript – Alex Slipknot May 10 '17 at 12:29
  • 2
    No client-side encryption tool is of any use at all. – Pointy May 10 '17 at 12:30
  • *"that requires an authentication process"* - which is what? Stating what that is exactly could have an effect as to what can be used and for comments/answers given. – Funk Forty Niner May 10 '17 at 12:34
  • If I can't use HTTPS, it's because I work on a domain that isn't mine, and the owners aren't OK to use HTTPS. – Ragagno May 10 '17 at 12:41
  • 1
    `"I know that anybody that could intercept the string could connect, but they couldn't know the password"` - To be specific... The person intercepting this information *does* know the password. They don't know the *original* password input by the user which may be used elsewhere (such as the same user's banking site), but they *do* know the password to *your* site. They also now know the hash, and the client-side code which generates it. So they can easily brute-force with common passwords. Your client may insist on not using HTTPS, but don't give them a false sense of security here. – David May 10 '17 at 13:26

1 Answers1

-5
    String.prototype.hashCode = function(){
    var hash = 0;
    if (this.length == 0) return hash;
    for (i = 0; i < this.length; i++) {
        char = this.charCodeAt(i);
        hash = ((hash<<5)-hash)+char;
        hash = hash & hash; // Convert to 32bit integer
    }
    return hash;
}

This is the method you can use to hash your password in JS

Courtesy : http://werxltd.com/wp/2010/05/13/javascript-implementation-of-javas-string-hashcode-method/

  • 5
    Surely anyone in the middle will have exactly what they need to authenticate with this? This may put the password into a different form, but it still exposes the password. – samiles May 10 '17 at 12:58
  • 10
    This is not a recognized way of hashing passwords, please don't use this code in any code that needs to be secure! – J.N. May 10 '17 at 14:19