Overkill or Secure?

[premiso]

Hey,

 

I am creating a login system and have been looking into using Javascript to hash user information on the client side and sending it over, so the data cannot really be sniffed by packet sniffers. (Not that I have had this happen but yea). I plan to use it on the registration form just for the Password. When a user logins, it will hash both the password and username. I plan to do an SHA1 hash and send it to my script, which in return would do a new SHA1 hash that is salted of that hash for the password (the password would be stored in the same fashion) and then hash the username from the database and check against that. If they match, they are logged in.

 

I think this may be overkill, but it also sounds like a fun project for me to do. I was wondering if anyone had any thoughts on why this would not work or any possible flaws in doing this?

 

I would also want to implement a hash check on the registration and or login form(s), if the hash does not match, reject the form. This would, hopefully prevent bots from registering or someone trying to bruteforce my system.  The idea would be to have a hidden input field with a random name (stored in session) and hash re-generated for each "attempt". 

 

Along with the above I will have a lock out of account after x attempts for x minutes. If an IP is seen hitting more than 1 account within x amount of minutes and getting passwords wrong, that IP is then temporarily banned for 20 minutes or so.

 

Well just wanted to see if I am overkilling it, or if that is good security measure to make sure my site is not hacked and my users information is safe.

 

Thanks for your responses!

[Daniel0]

Uhm... SSL?

[premiso]

Uhm... SSL?

 

lol, too cheap for SSL. I just thought it would be a good project to do, and I was just curious if it would make anything safer or not.

 

Really the data I am protecting is nothing more than addresses/email addresses. If I was handling CC information etc, I would definitely get an SSL Certificate. I just know my code is vunerable right now and I am looking into beefing it up.

[Daniel0]

Sure it'll be safer than plain text, but I only think it'll be marginally safer. Hashing it without a salt or with a publicly known salt isn't really that secure. HTTPS is secure because it encrypts it using the public key of the server, and the server can decrypt it using its private key. You can just make a self signed certificate or get a really cheap one. SSL is SSL regardless of the price you paid for the cert. It'll be the same encryption. The more expensive certs are expensive because they verify who the person/site is as well.

 

You can only do it for passwords and other info you don't ever need in plaintext again though. Email addresses don't work using your method.

[premiso]

Sure it'll be safer than plain text, but I only think it'll be marginally safer. Hashing it without a salt or with a publicly known salt isn't really that secure. HTTPS is secure because it encrypts it using the public key of the server, and the server can decrypt it using its private key. You can just make a self signed certificate or get a really cheap one. SSL is SSL regardless of the price you paid for the cert. It'll be the same encryption. The more expensive certs are expensive because they verify who the person/site is as well.

 

You can only do it for passwords and other info you don't ever need in plaintext again though. Email addresses don't work using your method.

 

Yea, that is actually what brought this up. I had to do some network training and they had Encryption using public/private key. It got me thinking of ways I could secure my site better.

 

But if it will only be "marginally" better (I had thought of that because JS would require the salt to be figured out/no salt). I may still try it, if I come across the time. I guess my main focus was trying to create something secure without the need for SSL, cause I know if the certificate is not signed/verified, you get that dumb warning everytime someone goes to your secure domain.

 

I do appreciate your comments/insight! It does make me think a bit more about it.  I am sure there is no other "securer" method than SSL, or else that would be used. But basically doing it my way would give me a "false" sense of security.

 

Thanks Daniel!

[corbin]

SSL was my first thought too ;p.

 

 

 

Anyway, what about the people with JS disabled?

[premiso]

Anyway, what about the people with JS disabled?

 

My site is fully based on JS, I do not offer alternatives lol, at least for login/registration/control panel.

 

If regular users have it disabled, too bad for them, it is a site requirement. For mobile based browsing I plan to have a limited functionality site setup.

[corbin]

Oh ;p.

 

 

I'm sure you could implement the RSA algorithm or something similar in JS.  (If you did RSA you would definitely want to look into optimizing it [Chinese remainder theorem and so on].)

 

 

"I would also want to implement a hash check on the registration and or login form(s), if the hash does not match, reject the form. This would, hopefully prevent bots from registering or someone trying to bruteforce my system.  The idea would be to have a hidden input field with a random name (stored in session) and hash re-generated for each "attempt"."

 

Why couldn't a smart enough bot find out which field name is dynamic?  Guess you're counting on no one putting that much effort into a bot for your site.

 

"Along with the above I will have a lock out of account after x attempts for x minutes. If an IP is seen hitting more than 1 account within x amount of minutes and getting passwords wrong, that IP is then temporarily banned for 20 minutes or so. "

 

That's not overkill at all, in my opinion.  In fact, lots of major sites do that.  It can be overkill in some situations though.  Brute forcing passwords over the internet really isn't very feasible without a giant bot net or something or a long, long time to wait.

[premiso]

The kicker on the has portion is it would require session, thus cookies. Being that, only web fetchers could potentially grab it.

 

But yea, I can see why the hashcheck may not work, I will have to revamp my idea on it a bit.

 

The IP blocking I do like, at least in the sense I described it. I am going to think on that one a bit more too. And I will also look into the RSA and see if I cannot work that out.

 

Thanks corbin, appreciate the responses!

[corbin]

Hrmmm just found some Javascript RSA implementations via Google, and it seems that JS actually isn't too slow with huge numbers and exponents.

 

(http://ohdave.com/rsa/)

 

 

"The kicker on the has portion is it would require session, thus cookies. Being that, only web fetchers could potentially grab it."

 

 

What do you mean by web fetchers?  Do you mean web fetchers as opposed to programs that just send a request to the page they want to begin with?

 

 

 

 

 

And uhhh no problem in response to the appreciation thing.  lol.

[Daniel0]

I would also want to implement a hash check on the registration and or login form(s), if the hash does not match, reject the form. This would, hopefully prevent bots from registering or someone trying to bruteforce my system.  The idea would be to have a hidden input field with a random name (stored in session) and hash re-generated for each "attempt".

 

I overlooked this. It won't protect you from what you intended, but it's excellent for blocking CSRF attacks.

[premiso]

I overlooked this. It won't protect you from what you intended, but it's excellent for blocking CSRF attacks.

 

Gotcha.

 

Well, I have been reading up a bit on Cryptology. And I think the best way, if I want to do this, would be to implement a form of RSA via Java/Javascript. Since I would really only need it on 2 pages, I may just do that. As I understand it, that is all SSL really is. A 128bit key encryption with a Public/Private key through a certificate, which can be "Verified" if you want to pay out the money. SSL is probably more secure than how I am planning on implementing the RSA, but as it is this is a learning process for me understanding how different cryptology's work. I know that if someone wants to break a sent encrypted message, they will, but why make it easier for them?

 

Thanks both of you. I am going to be doing a lot of reading the next few days and see if I cannot get my head wrapped around some more of this stuff. I actually read the RSA wiki. Amazing that a method made back in the 1970's is still used today as a secure encryption. But I guess if a method is not known fully to the public of what it can do for 20 years, that has it's advantages of being secure longer.

 

@corbin: regarding the Chinese version, it looks like that is very simple to crack after reading over the wiki. The upside was it is quicker, downside it has a major loop hole.

 

Thanks guys! I am just trying to figure out different methods of doing stuff, you can never learn too much! The day I stop learning, is the day that I die.

[corbin]

Implementing the Chinese remainder theorem shouldn't be a security problem x.x.  Weird.  *goes to read through the wiki again*  It's just a shortcut to know that a % b = c without doing a % b.

 

 

In most cases that wouldn't be necessary anyway.  If you're doing small keys and small blocks of data, just doing it straight-up (for lack of a better term) should be fine.

 

"I know that if someone wants to break a sent encrypted message, they will"

 

Imagine how long it would take to break a hrmmm... AES-256 (first strong encryption that came to mind) encrypted message.

[premiso]

"I know that if someone wants to break a sent encrypted message, they will"

 

Yea, I was reading different encryption types and it all depends on the key you use and how long it is. They suggest using a key that would take 10,000 years of computer processing time to solve it, and have it expire every x amount of time and re-create a new one.

 

Anyhow, I am really getting into the cryptology. I am going to keep on reading and try and learn some fun stuff with it.

[Daniel0]

You're going to need some somewhat advanced math if you're really going into cryptology.

[premiso]

You're going to need some somewhat advanced math if you're really going into cryptology.

 

Yea, I am taking a Calculus class next semester to further my degree and I will probably keep going on that tangent.

 

I enjoy math, but it has been a while since I was in a class, since my Associates degree in college for Pre-calc. But yea, I kind of gathered that hint when they are talking about how they generate the encrypted message and decrypt it.

 

But yea, I definitely want to go more in-depth in math in my studies to hopefully understand this alot more. Hmm, I should look into seeing if they have a "cryptology" class and check out the pre-reqs.

[corbin]

Hrmmm a cryptography class would be quite interesting, I must say.

 

Perhaps I should copy you and check if the college I plan on going to has something like that lol.  Wonder how many people have taken cryptography (if the university has it) as an elective before haha....