1

I am working on a website to learn more about web programming and also to launch same as a start-up. The first problem that i came across was how to implement a secure login system. Currently i have take steps like escaping the password and then hashing it, using a salt. But i was wondering is the following mechanism secure,

  • I will make the user enter username and will keep checking if the user has entered his username (when textbox loses focus or a button for submitting username, also to prevent listing of usernames ill block the user by setting cookie on system if multiple incorrect attempts are made, or maybe ill use captcha for each ), once entered username, ill send back random stored salt to user.
  • Using that salt and password entered, user will hash the password and send it in form
  • I'll verify the password by comparing hashes

I think it will be beneficial since server side i don't have to do any processing, and hence i don't have to worry about DoS attack, as i read somewhere that using some slow hashing like BCrypt will expose site to DoS attacks. Also user's password is never communicated over the network, making it secure from person sniffing the network.

Please do point me to some reference or anything that may help me to implement securely. Consider me noob because i have still started learning, and would like to know what you think of it, what possible flaws are there ? and what must be secure strategy.

UPDATE- Many answers i am getting, all usually assume that i am thinking this as an alternative to SSL; no it's not the case. By protection against sniffing i meant protection just in case some attacker might make the user use a SSL proxy. just for reference - https://security.stackexchange.com/questions/19616/why-is-it-possible-to-sniff-an-https-ssl-request

Community
  • 1
  • 1
Dapu
  • 195
  • 1
  • 3
  • 13
  • 2
    And what makes you think that you can't be DoS attacked, simply because you're hashing the password client-side rather than server-side? – Mark Baker Mar 19 '15 at 10:01
  • 1
    And why do you think a user won't simply delete the cookie that you use to block multiple failed attempts? – Mark Baker Mar 19 '15 at 10:02
  • I am not saying that this is going to prevent all possible ways to launch a D0S attack. It just reduces one possibility. And i can use SSL, but i wanted to know how effective is this. Being hones i am not much aware of how exactly SSL works, i know only this much that it encrypts the data, adding little more to server's load. – Dapu Mar 19 '15 at 10:04
  • I still have a captcha, there can be so many workaround to it, lets say for example if incorrect username, i will send incorrect salt – Dapu Mar 19 '15 at 10:04
  • @MarkBaker consider a scenario, where an attacker gets hold of usernames and changes IP frequently, won't it be a problem if i use slow hashing on my server ? – Dapu Mar 19 '15 at 10:33
  • I can't even see how it reduces even one possibility of a DoS attack.... joe malicious can still hit your server as many times as they want, irrespective of how you implement your security – Mark Baker Mar 19 '15 at 10:35
  • @MarkBaker Please read my last comment. Don't u think its a possible DoS attack ? – Dapu Mar 19 '15 at 10:36
  • A DoS has nothing to do with an attacker trying to break passwords, and everything to do with overloading your servers..... it's about making thousands of requests per minute/second.... nothing you've suggested here prevents that – Mark Baker Mar 19 '15 at 10:37
  • @MarkBaker you are right they may hit.. but it depends on impact of hit too. On every hit if i have to hash a password using some slow hashing, isn't it too much for my poor server to bear ? – Dapu Mar 19 '15 at 10:37
  • @MarkBaker DoS is when server gets overloaded with lot of CPU work. And solving hash on every request surely makes it overload..Please read here also, just googled this link.. http://security.stackexchange.com/questions/20778/should-you-care-about-dos-attacks-if-your-server-is-using-bcrypt – Dapu Mar 19 '15 at 10:39
  • Whether quick or slow hashing; thousands of requests per second is going to overload your server no matter how quickly you process them – Mark Baker Mar 19 '15 at 10:39
  • But slow hashing helps prevent brute force attacks – Mark Baker Mar 19 '15 at 10:40
  • @MarkBaker If only purpose of slow hashing was to prevent brute force(in case you are referring to using brute force online) then why is disabling of accounts after multiple attempts for ? Slow hashing is used to make sure that in case database is popped out then attacker doesn't get hold of passwords easily. Even with sophisticated hash cracker ASIC out there. And you are right, many requests will surely cause a DoS but my point is, if 1000 request may overload server. then if those request are to verify password, then it will take only 100 request rather than 1000. – Dapu Mar 19 '15 at 10:44
  • Oh thank you for not wasting my time either... Have a nice day :) i am sure there must be flaws that's why i put it up here and probably someone else will surely explain what are those. With some decency and not just by starting with a line "Just use SSL like normal developers ". – Dapu Mar 19 '15 at 11:01
  • 1
    You shouldn't hash in the browser, that's how phpbb got into trouble a couple of years ago, because they you have to hash the hash when you get to the other side and double hashing can actually make the password more predictable. And at that point anyway the hashed password is equivalent to a raw password. – Elin Mar 19 '15 at 15:52
  • 1
    If you are just learning about web development and you want to produce an actual working application authentication, which is very hard to do correctly, is not a good place to start. Use a framework and if you want to learn study how the good php open source applications do it, but I urge you to not try to implement it for real by yourself. If it is just for learning maybe but even there how are you going to get serious code review from an expert? – Elin Mar 19 '15 at 15:56
  • @Elin Thanks for valuable feedback, i would like to learn more about phpbb vulnerability you mentioned. It would be great if you can point me to any link so i can learn more about it. And also i am calculating hash just once on browser side and making him send it to server just for comparing it. I never prefer to use framework for application since i believe if a vulnerability is found and any attacker who gets to know about framework on my site will surely exploit it, even before the community managing framework or i fix it. – Dapu Mar 20 '15 at 06:13
  • 1
    Counting on no one bothering you because you are not using a framework is ignoring the fact that threats from people you know are especially dangerous. If you think that you won't have to rehash server side you don't understand that anyone could then look at your data base and know what password to enter. http://stackoverflow.com/questions/348109/is-double-hashing-a-password-less-secure-than-just-hashing-it-once http://stackoverflow.com/questions/8611050/does-encrypting-a-password-multiple-times-really-make-it-more-secure?lq=1 https://www.owasp.org/index.php/How_to_write_insecure_code – Elin Mar 20 '15 at 17:04
  • Even if i rehash, then also they can determine what password to enter. It would be too quick if i don't use salt, and if i use salt...even then it will be quick, because salt will also be there in database. And i never said that ignoring framework will move attention of attackers away from me, what i said was that frameworks mostly are opensource or are accessible to whole community out there, so if a bug is found by anyone out there it goes public soon. whereas that is not the case if i avoid framework. I hope i explained well what i am trying to say. – Dapu Mar 20 '15 at 18:14

4 Answers4

3

Client side hashing can have its advantages, but you cannot do without server side hashing. In your scenario, the calculated hash acts as the new password. An attacker with read access to the database (SQL-injection) will see this hash and can use it directly as password to login.

Using a slow hash with a cost factor is mandatory, usually it is done server-side, because client-side languages are slower and can do less rounds. Of course somebody can use it to make a DoS attack, but this can be done with every other page as well. The size of the password doesn't matter (as one can read ocassionally), because after the first round only the hash will be hashed.

If you plan to do a client-side hashing, don't forget to calculate a (fast) hash on the server as well. And you have to ensure, that the hashing was done correctly client-side. Much more important is, that you use SSL to send the credentials.

The question Secure authentication: partial client-side key stretching… could be of interest to you.

EDIT:

I will try to sum up the important points for client-side hashing.

  1. A slow hashing algorithm with a salt and a cost factor (BCrypt/PBKDF2/SCrypt) is mandataory, this is the only thing that makes it hard to retrieve the original password from a hash, if the password is weak. It is possible to do this client-side.
  2. Server-side hashing is mandatory too, to prevent an attacker from using stored hashes directly as passwords, if he knows them. The hash can be fast without a salt (SHA-256), because the input (BCrypt hash) has enough entropy. Such a strong "password" with 60 characters cannot be successfully brute-forced.
  3. If the attacker cannot crack the fast SHA-256 hash because the input is too strong, he can try to brute-force with the original passwords (from a dictionary). But to do this he would first have to calculate the slow BCrypt hash and afterwards the fast SHA-256 hash.
  4. Client-side languages like JavaScript are usually interpreted and much slower than compiled code, so you can do less rounds in the same time as you could do on the server (this weakens security). If you have the possibility to run native code on the client, there is no disadvantage to do the slow hash client side.
Community
  • 1
  • 1
martinstoeckli
  • 23,430
  • 6
  • 56
  • 87
  • "A ManInTheMiddle will see this hash and can use it directly as password to login." A MIM attack can also see regular text password, and that will be more of a problem. And yes its a very good point that you mentioned, that client side languages are slower. But i think it won't be noticable. But it will be noticable load on server, since server has to hash multiple user's passwords. i would like to learn more about why should i rehash password on server ?. – Dapu Mar 20 '15 at 06:24
  • Also for last point i assume the hashing will always be correct unless user alters some script on his side, which will only result in no access to user. And yes i will use SSL no matter if i am hashing client side or not. – Dapu Mar 20 '15 at 06:24
  • " And yes its a very good point that you mentioned, that client side languages are slower." sorry for this comment, but its actually system which are some times slower not languages. – Dapu Mar 20 '15 at 06:58
  • 1
    No, because the MIM will not know the salt. – Elin Mar 20 '15 at 17:07
  • 1
    @Dapu - You are right that a MIM attacker would also see the plain text password, that's why you need SSL. What i had in mind is, that if somebody is able to read the hashes from the db (SQL-injection), he could use them directly to login, this you can prevent with doing another hash server-side. The server-side hash can be unsalted and fast, because the entropy of the input is always very high (the BCrypt hash). Unfortunately using JavaScript to calculate the hash client-side **is** significantly slower, so it is not the system that is slower, the usually available interpreting language is. – martinstoeckli Mar 21 '15 at 12:03
  • @martinstoeckli oh yes, actually in scenario the db is popped by attacker a quick hash server side is very helpful, thats a **great point that entropy will be high** for input. I didn't had that in mind. It will add little security, because even if he is having hash from high entropy input, he still can brute force a password (hashing two times the password, and not all users have long and complex passwords, so its a matter of small time that it will take for him to crack a password). ...continue next comment... – Dapu Mar 21 '15 at 13:03
  • In any case if DB is compromised then there is hardly anyway which could stop an attacker for taking out passwords, But yes hashing them again does at a little security to it. But yes it will ensure that rainbow and lookup tables fail, because salt will be there, which becomes ineffective if i don't hash on server side.For language, i believe its not language which is faster, its only system specs and purpose of use. Server usually will have more power but it has more work to do also. Only problem as i mentioned in my answer , seems to arise when using low-end devices like mobiles. – Dapu Mar 21 '15 at 13:03
  • 1
    @Dapu - I'm not sure you understood it all correctly. Hashing is done _exactly_ to protect passwords in case somebody could read hashes in the database, it _is_ possible to stop an attacker. Salting on client-side (BCrypt) and hashing server-side (SHA-256) is done to protect from different things. I made an update to explain it more clearly. Maybe you are also interested in my [tutorial about safely storing passwords](http://www.martinstoeckli.ch/hash/en/index.php). – martinstoeckli Mar 21 '15 at 14:09
  • @martinstoeckli I mentioned **"But yes hashing them again does at a little security to it."**, but after reading your update i feel actually its not just little but a good amount of security, cause i forgot that even if he tries to brute force then BCrypt will make it tough for him. Thanks for such a nice explaination and your time too. I think i won't be getting more answers, and possibly not better than this. So i will mark it as answer. And thanks for explaination why javascript will be slower. Really got to learn a lot. – Dapu Mar 21 '15 at 14:54
  • @martinstoeckli Also is there a way on StackOverflow using which i can invite you to a question to answer it. Because i have few more questions related to securing the site. – Dapu Mar 21 '15 at 14:57
  • @Dapu - Just use the `password` tag and i will very likely find your question. Aside from that you could visit my homepage, there you can find my email. – martinstoeckli Mar 21 '15 at 15:06
0

no, you should not send any 'salt' to the user. It can be sniffed.

What you're basically doing is a send something like a (csrf-)token that can be used once. Nothing wrong with that, but you seem to be re-inventing the wheel.

Alex
  • 5,759
  • 1
  • 32
  • 47
  • Even if someone sniffs the salt, its of no use to an attacker, Since salts are different for each user. Also for the victim attacker wont be able to use that salt with multiple combinations of password, since it gets blocked on say 10 attempts. rendering it not useful. – Dapu Mar 19 '15 at 10:41
  • you clearly don't know what a man-in-the-iddle-attack is. And just like everyone else is saying: no, your strategy wont help at all. – Alex Mar 19 '15 at 10:44
  • I know what is Man in Middle attack, and thanks for you answer. I don't think discussing this further with you will lead to anything constructive. – Dapu Mar 19 '15 at 10:45
0

Seriously, I think your solution is good only for hackers. If I sniff communication I will get gradually username, salt and password hash. You have to send all those values over the network (username to get salt, password hash to auth attempt). Now I can use sniffed password hash directly in malicious login request or start cracking password locally (users usually have same password for more services). All checks and limits on auth attempts are out of game because I don't need send request to guess password. Depends on hash algorithm it will more or less time consumption. I think network sniffing is the main purpose why you calculate with not sending plain password over the network.

You can secure your network communication with TLS but then all things with sending salt and hashing password on client are unneccessary. You can just send password in plain text to server. But yes, hashing password on client, why not if you want. You can use ie. sha1 also on server if you think that bcrypt is performance issue and possibly DOS cause.

Good example of protocol that is used for transmitting infomation through unsecure network is OAuth 1.0a and even in it you need some cryptography or TLS for transfering consumer secret.

Let me know if I am something understood incorrectly.

kba
  • 4,190
  • 2
  • 15
  • 24
  • For your first point "Seriously, I think your solution is good only for hackers. If I sniff communication I will get gradually username, salt and password hash.", don't you think that its even more a problem if they sniff password itself and not hash? they don't even need to solve the hash. and no, network sniffing is not the purpose i thought of this solution, my main aim is to reduce server side complexity and make sure that the user password never leaves his system, even on network. Just a hash of password leaves his system. and yes i like your point very much of using OAuth. i'll learn it – Dapu Mar 20 '15 at 06:29
  • 1
    You are limited with cryptography in client browser. If you use quick hash function it is not a big obstacle. So the password never leaves the client but normal passwords can be cracked relatively quick. If you want to create hash only on client, you are also forced to have this hash in database. – kba Mar 20 '15 at 09:11
  • Yes you are right a quick hash is needed, that too only on low-end devices. can you elaborate how it can be cracked ? and also even if i compute hash on server side, then also i have to store hash in database. – Dapu Mar 20 '15 at 09:50
  • By low-end devices i mean only mobile devices which are having less power of processor – Dapu Mar 20 '15 at 09:52
  • 1
    It could be cracked with bruteforce force attack techniques. No each user has ten chars long password with all characters. I mean you don't have possibility to use stronger hash in database then you got from the client. That's all. – kba Mar 20 '15 at 10:28
  • It can be cracked only if attacker knows hash, if attacker can get hash then he can get plain text password too, hash in fact implements more security by making job of attacker little more tough, isn't it ? also he is calculating the same hash that i would have used on my server while he registered. So i don't think its a issue. Correct me if m wrong – Dapu Mar 20 '15 at 10:51
0

I guess only drawback i can see is using this on low-end mobile devices.

Dapu
  • 195
  • 1
  • 3
  • 13