| Author |
 Topic  |
|
|
-gary
Development Team Member
406 Posts |
 Posted - 13 March 2006 : 19:12:05
|
Currently, a username and password are stored in a member's cookie. The two problems I have with it are that changing a member's name results in them not being automatically logged in the next time they return. If you do not properly notify members that their username has been changed by email, they are unable to log in. Sure, they should know that it was going to be changed, especially if they requested it, but the first thing that pops into their minds is that something is wrong.
Second, the users complete password is stored in the cookie and transmitted frequently between browser and forum. Granted, it is a hash but a brute force attack can crack most passwords in 2-4 days. Also, it would be possible to alter the username in the cookie sequentially to try and find a member with the same password via a script. This is something that probably isn't watched by login monitor if someone has implemented one.
My answer to number 1 is to store the member id in the cookie instead of username.
Number 2 is to store a unique hash for each member in the DB. Take a difference of the hash of their password and the unique hash and use it to verify the user. The unique hash is never exposed to the world in any form so it would be impossible to get without a larger security issue.
Example: A member submits their password for approval, it is hashed with SHA256 and then ran through a function like the one below. If all matches then the difference hash is returned as the validator instead of their hashed password.
The password would only be transmitted occasionally when the cookie expires or during profile changes, but never at any point would the full password be stored on the client machine in any crackable form. Even with that hash in hand all you would be able to crack is the difference key and I can't see where that would get you very far.
It may seem like a little overkill, but I think the current method may be a bit lacking. Yes, someone can sniff and pull your plain text password on full login and profile changes, but those are brief exposures compared to the cookie transfer and permanent storage of the password on a local machine.
Quick example.
strPWD = SHA256("password")
strSeed = SHA256("some random unique value")
strSecure = ""
For i = 1 To Len(strPWD)
If Asc(mid(strPWD, i, 1)) > Asc(mid(strSeed, i, 1)) Then
strSecure = strSecure & Asc(mid(strPWD, i, 1)) - Asc(mid(strSeed, i, 1))
Else
strSecure = strSecure & Asc(mid(strSeed, i, 1)) - Asc(mid(strPWD, i, 1))
End If
Next
strSecureHash = SHA256(strSecure)
< |
KawiForums.com
 |
|
|
ruirib
Snitz Forums Admin
Portugal
26364 Posts |
Posted - 13 March 2006 : 19:58:27
|
The suggestions you make are interesting, specially the 2nd one. Seems a bit safer than the current implementation, even if I would find it weird that someone would take a whole lot of computing time to brute force the finding of a forum password...
Frankly, I don't see 1 as a major problem. Cookies do expire occasionally and you need to login again. Also, if a username changes, I'd expect to have to login again, at least I wouldn't find it weird. Anyway, I think both changes could contribute to a more safe and reliable login process, so I'd say the changes are worth considering.< |
Snitz 3.4 Readme | Like the support? Support Snitz too |
 |
|
|
-gary
Development Team Member
406 Posts |
Posted - 13 March 2006 : 21:31:57
|
| I know a few people that would kill to get an admin password to my forum just to delete me.< |
KawiForums.com
|
|
|
|
Shaggy
Support Moderator
Ireland
6780 Posts |
Posted - 14 March 2006 : 07:24:46
|
The second one is something that has concerned me mildly for some time as well and definitely worth taking into consideration for future versions.
The first issue doesn't worry me as much as my members are sent an e-mail notification upon any change of their username, whether requested or not, informing them of the change and the need to log in again using their new name and existing password. Perhaps, though, an automated e-mail could be added to the profile modification process, if a username has been changed?
< |
 Search is your friend
“I was having a mildly paranoid day, mostly due to the
fact that the mad priest lady from over the river had
taken to nailing weasels to my front door again.” |
|
|
|
MarcelG
Retired Support Moderator
Netherlands
2625 Posts |
Posted - 14 March 2006 : 09:28:58
|
Not that I have anything to input to the dev track, but I applaud this proposed way forward!
Security and confidentiality is vital to every community out there, and if we can contribute to this by means of your suggestion, it's very much worth investigating/implementing in test environments.
When it comes to implementing it on existing boards (let's say in 3.4.06, have you considered the steps necessary to achieve that ?
I suppose it would mean a DB change (to add the userspecific hash) and some code changes, but not much more than that. Or am I missing something ?< |
portfolio - linkshrinker - oxle - twitter |
Edited by - MarcelG on 14 March 2006 09:29:54 |
|
|
|
Davio
Development Team Member
Jamaica
12217 Posts |
Posted - 16 March 2006 : 00:53:25
|
Both sounds good to me.
In relation to #1, is a little problem that I am concerned about. We rely so much on the email functionality of the forums, to send a message to a member. And email is not all that reliable, as there can be many scenarios as to why an email didn't reach the recipient. I think the only thing that email is needed is for account and email verification (registration and password changes), along with notification of replies. Rest should be kept within the forum.< |
Support Snitz Forums
|
|
|
|
StephenD
Senior Member
Australia
1044 Posts |
Posted - 08 June 2011 : 09:25:16
|
| Well, time has marched on and I believe current GPU card technology has improved brute force attack speeds enough so that it has started to worry me a bit. Been looking at this product https://www.shieldpass.com/index.html which seems to work like captcha but on logon and hope to setup a test site shortly. |
|
|
|
MarcelG
Retired Support Moderator
Netherlands
2625 Posts |
Posted - 08 June 2011 : 12:30:02
|
The simplest way to improve your shield against brute force attacks based on cracking the hashes found in cookies is by using a salt.
I've implemented it a while ago on oxle: http://oxle.com/topic/6058.html
The thing that still could be improved is the actual loginprocess, in which we now are vulnerable to sniffing unless you're hosting on HTTPS ; passwords are sent over the line in plain text (the hash isn't calculated at the client, but on the server). Only áfter that initial login process the cookie is filled with the (salted, virtually uncrackable) hashed password, but that cookie can also be grabbed using sniffing tools. Once grabbed, a session could be hijacked....
Without using HTTPS it's not possible to solve it entirely, but I think that improvements might be possible, by for example performing a client side hash generation, however with that the salt must be visible for the world to see....aaargh, I know too little about cryptography to solve this one. |
portfolio - linkshrinker - oxle - twitter |
|
|
| |
Topic |
|
|
|
Request for comments: Cookie authentication change
