 |
|
Main
| FAQ
| Uploader
| IRC chat
| Radio
| Memberlist
| Active users
| Latest posts
| Calendar
| Stats
| Online users
| Search
| |||
| Views: 88,536,541 |
Main
| FAQ
| Uploader
| IRC chat
| Radio
| Memberlist
| Active users
| Latest posts
| Calendar
| Stats
| Online users
| Search
|
05-05-24 03:11 AM |
|
| Guest: Register | Login | |||
| 0 users currently in Help/Suggestions/Bug Reports | 1 guest |
| Main - Help/Suggestions/Bug Reports - Passwords... | New thread | New reply |
| Black Lord |
| ||
 Red Cheep-cheep Level: 35 Posts: 100/220 EXP: 258675 Next: 21261 Since: 02-19-07 Last post: 5430 days Last view: 5430 days |
Is it a possibility to 'salt' our passwords so even if someone acquires our md5 hash, they still can't do much with it.
Just something I'm throwing out there. ____________________  |
| Kernal |
| ||
|
Gone Level: 88 Posts: 1802/1881 EXP: 6466658 Next: 184006 Since: 02-20-07 Last post: 6155 days Last view: 6146 days |
Excuse my n00bness, but what is salting? Is that where you take the hash of the password plus an additional chracter or string, so the hash isn't recognizable or whatever? |
| Stifu |
| ||
 Cobrat Level: 56 Posts: 145/666 EXP: 1362234 Next: 35942 Since: 02-22-07 Last post: 694 days Last view: 316 days |
Posted by Kernal Yeah basically... and the salt changes each time, too. |
| Xkeeper |
| ||
|
Level: 105 Posts: 2081/2846 EXP: 12036555 Next: 225705 Since: 02-19-07 Last post: 6068 days Last view: 2806 days |
Making it change each time is a little more difficult, really  ____________________ I dealt with it. |
| Black Lord |
| ||
|
Red Cheep-cheep Level: 35 Posts: 101/220 EXP: 258675 Next: 21261 Since: 02-19-07 Last post: 5430 days Last view: 5430 days |
Posted by Xkeeper Not really, as long as you store what the salt is for each user, having a random salt isn't really that hard. I've actually got it working pretty slick on something I'm developing. ____________________ |
| DarkSlaya |
| ||
 Cheep-cheep Level: 32 Posts: 129/189 EXP: 205982 Next: 460 Since: 02-19-07 Last post: 6010 days Last view: 6002 days |
wait.
The way I see it, if they get the cookie, it's still game over. |
| Black Lord |
| ||
|
Red Cheep-cheep Level: 35 Posts: 102/220 EXP: 258675 Next: 21261 Since: 02-19-07 Last post: 5430 days Last view: 5430 days |
The salt is stored in the database...
The cookie contains id and password... When user logs in, first grab users salt from database, append salt to password, encrypt password and match to previously encrypted password + salt in database. If does not match, login fails. If your interested I could get you a my incomplete (very incomplete) User class from my current project so you can see how it's done. ____________________ |
| Cellar Dweller |
| ||
 Snifit Level: 39 Posts: 32/287 EXP: 385453 Next: 19318 Since: 02-19-07 From: Arkansas Last post: 4060 days Last view: 3228 days |
Posted by DarkSlayaA couple of ideas come to mind to deal with stolen cookies. The first one is to use opaque session keys. When a user logs on, a large random session key is generated and stored in a table with the id of the user and optional IP and/or User-Agent restrictions. The session key is issued in a cookie. If the cookie is stolen, the IP/User-Agent restrictions might not be met and the logon would not be recognized. If the user forgot to log out after using a public computer, they can log out that session from another computer. Another way to do it is to issue cookies that are encrypted with a site specific key. A delimited string containing the user id and optional IP and/or User-Agent restrictions. This string is checksummed. The checksum and original string are encrypted and issued in a cookie. If the cookie is tampered with, the decrypted contents will be mangled and the checksum will be invalid. If the user's password hash is included in the encrypted cookie, all issued cookies can be rendered invalid by the user changing their password. A salt might be useful to add to the mix, but I'm not sure it is. In both cases, the current password can be required to change the password. This will prevent a complete takeover if an attacker is able to use a stolen cookie. The IP/User-Agent restriction could be set a login time. For example, if the user is logging on from their home desktop he can set a strict IP restriction because IP changes should be rare. For a laptop, a looser IP restriction may make more sense. |
| DarkSlaya |
| ||
|
Cheep-cheep Level: 32 Posts: 130/189 EXP: 205982 Next: 460 Since: 02-19-07 Last post: 6010 days Last view: 6002 days |
Yeah, I had similar ideas to yours.
Because honestly, the problems are: 1- Stolen cookies. 2- Using same pass on multiple websites. |
| Xkeeper |
| ||
|
Level: 105 Posts: 2086/2846 EXP: 12036555 Next: 225705 Since: 02-19-07 Last post: 6068 days Last view: 2806 days |
I was actually thinking about IP-based cookie restriction, but without a way to determine who needs it and who it would just fuck with, I left it out
I could always implement "Pick your own security level" (ala Gunbound), with "high, medium, and low" representing the number of octets in the IP address it looks for. ____________________ I dealt with it. |
| Kernal |
| ||
|
Gone Level: 88 Posts: 1803/1881 EXP: 6466658 Next: 184006 Since: 02-20-07 Last post: 6155 days Last view: 6146 days |
Problem with that is people who use multiple IP addresses regularly. I post from both home and work, and my IPs for each place are wildly different. There's also the problem if someone moves (which I did in April and will probably do twice in 2008). |
| Xkeeper |
| ||
|
Level: 105 Posts: 2099/2846 EXP: 12036555 Next: 225705 Since: 02-19-07 Last post: 6068 days Last view: 2806 days |
I was actually planning on it turning your cookie-password into "yourpass-##.##.##.##", and hten just doing a MD5 check against the database for it...
Actually making it reject users just because of an IP change would fuck over people who use AOL or dialup, for example, and I don't want that. ____________________ I dealt with it. |
| Kernal |
| ||
|
Gone Level: 88 Posts: 1804/1881 EXP: 6466658 Next: 184006 Since: 02-20-07 Last post: 6155 days Last view: 6146 days |
Yeah, there's that too...and when I had dialup in 2001-2005, the IPs usually were pretty similar for a while (like 65.164.xxx.xxx), but at some point the ISP apparently switched to a completely different range of addresses starting with 216. Another reason why even checking only the first octet can be very bad. |
| Xkeeper |
| ||
|
Level: 105 Posts: 2100/2846 EXP: 12036555 Next: 225705 Since: 02-19-07 Last post: 6068 days Last view: 2806 days |
I just realized, my post makes no sense if you don't immediately understand what I mean.
In any case, the cookie would be bound to the IP address it was sent from; i.e. you could log in from A, log in from B, but as long as A's ip address never changed outside of the "security range", you would be ok. For example, you could set a security range of "two", which would append "-xx.xx" to the (pre-MD5) cookie your browser is sent. The board would look up your user info and see your cookie security, and then determine if it was still valid from it. Dialup users could just set a lower level, (or disable it) for exmaple. This way someone who simply steals your cookie will have trouble brute-forcing it, as it's salted (via IP) and made longer than most dictionaries. ____________________ I dealt with it. |
| DarkSlaya |
| ||
|
Cheep-cheep Level: 32 Posts: 134/189 EXP: 205982 Next: 460 Since: 02-19-07 Last post: 6010 days Last view: 6002 days |
or you could have your idea that could screw up dialup users and have an option to use it or not. |
| Xkeeper |
| ||
|
Level: 105 Posts: 2101/2846 EXP: 12036555 Next: 225705 Since: 02-19-07 Last post: 6068 days Last view: 2806 days |
Posted by XkeeperOr you could just fucking read my ____________________ I dealt with it. |
| DarkSlaya |
| ||
|
Cheep-cheep Level: 32 Posts: 135/189 EXP: 205982 Next: 460 Since: 02-19-07 Last post: 6010 days Last view: 6002 days |
That would work too  |
| Main - Help/Suggestions/Bug Reports - Passwords... | New thread | New reply |
© 2005-2023 Acmlm, blackhole89, Xkeeper et al. |
|
MySQL - queries: 77, rows: 102/103, time: 0.013 seconds. |