Today's Posts Follow Us On Twitter! TFL Members on Twitter  
Forum search: Advanced Search  
Navigation
Marketplace
  Members Login:
Lost password?
  Forum Statistics:
Forum Members: 24,254
Total Threads: 80,792
Total Posts: 566,471
There are 1070 users currently browsing (tf).
 
  Our Partners:
 
  TalkFreelance     Design and Development     Programming     PHP and MySQL :

Password encryption?

Thread title: Password encryption?
Closed Thread  
Page 4 of 4 < 1 2 3 4
    Thread tools Search this thread Display Modes  
02-24-2007, 01:39 PM
#31
Chaos King is offline Chaos King
Status: Member
Join date: May 2006
Location:
Expertise:
Software:
 
Posts: 119
iTrader: 4 / 100%
 

Chaos King is on a distinguished road

Send a message via AIM to Chaos King Send a message via MSN to Chaos King

  Old

Ouch. Looks pretty painful to even look at. =) Good job. Thats a nice function there. Kinda like overkill, but security is key for any website =)

02-24-2007, 02:46 PM
#32
Andrew R is offline Andrew R
Status: Request a custom title
Join date: Dec 2005
Location: Arizona
Expertise:
Software:
 
Posts: 5,200
iTrader: 17 / 95%
 

Andrew R is on a distinguished road

  Old

JochenVandeVelde: That's what I call encryption.

02-24-2007, 07:07 PM
#33
RaZoR^ is offline RaZoR^
RaZoR^'s Avatar
Status: Member
Join date: Feb 2006
Location:
Expertise:
Software:
 
Posts: 191
iTrader: 1 / 100%
 

RaZoR^ is on a distinguished road

  Old

Originally Posted by echoSwe View Post
Yes, but a salt is different for every row in the database, not hard-coded like you wrote...

You should create password criteria at sign-up.
However, whether they use 'password' as their password or not is really not interesting in this discussion, but rather how to store their password in a way that doesn't open too wide avenues of attack. You should create password criteria at sign-up...
It depends. Neither of us are wrong You can have a static salt, which is hard coded into the PHP script. This is more practical in PHP, but you can also set a random salt and prefix the password with it before encrypting with the chosen algorithm. The salt would then be stored in the database though, which means if an attacker wanted a specific password, then could make a program to brute-force or dictionary attack the password still. Each method has advantages and disadvantages.

Set String:
+ Salt is only available from the script; attackers would need file access as well as database access;
+ The salt can be changed if it is found to be discovered;
- If the salt is discovered, tables can be generated to calculate all the passwords.
- A user could sign up with a password and grab their hash from any cookies; from here they could brute-force the salt and generate tables to crack all the other passwords.

Random String:
+ The salt is different for each password, and so tables can not be generated at all;
+ The salt is not stored anywhere, and providing a proper random function is used (not a calculation), then the salts can not be re-calculated for each password;
- The salt for each password need to be stored somewhere in correspondence with the hash; this leaves space for an attacker to find the salt for a specific password.

Nice function JochenVandeVelde lol... it'd take a decent computer about a year to crack one of those passwords if it's length was 0 > l >= 6 characters I reckon!!

02-24-2007, 07:30 PM
#34
echoSwe is offline echoSwe
Status: Member
Join date: Jul 2005
Location:
Expertise:
Software:
 
Posts: 185
iTrader: 0 / 0%
 

echoSwe is on a distinguished road

  Old

First of all: HASHING DOES NOT EQUAL ENCRYPTION, OMG! Glad to have that out of my system once and for all. Now let's not mention it again.

I think you need to understand some stuff. The random salt MUST be stored somewhere, or you can't get the hash corresponding to password+salt when the user logs in next time, so the salt IS STORED somewhere.

Also, if your static "salt" is discovered, how would you change it? You can't get the saved password data back, without explicitly adding a check on the next time the user logs in and if the user has the 'old' hash, update the saved password data. And if it's discovered, you don't 'calculate' passwords, as much as you compare the hashed dictionary against the saved hashes. You must also ask yourself the question whether your hosting company completely trustworthy, and even if you come to the conclusion that they are 99%, why risk it by storing the hash like you have?

And how would the user 'grap their hash' exactly? It's not like you save their password or rather their corresponding hash, in a cookie, but rather just send an authentication cookie, with a unique identifier, other than the hash. Also, how would the user connect to the data storage if they 'grap their hash from the cookies'?

The fact that no tables can be generated at all if the salt is unique for every password, is imho the point I'm trying to make here. Why put yourself in a situation where you don't have a more secure solution if it can be done in a minimal amount of work?

"Without salts, an attacker who is cracking many passwords at the same time only needs to hash each password guess once, and compare it to all the hashes. However, with salts, all the passwords will likely have different salts; so each guess must be hashed separately for each salt, which is much slower since hashing is usually very expensive." http://en.wikipedia.org/wiki/Salt_%28cryptography%29

Which extends to that a static hash which is discovered is just as safe as if you had no salt at all.
http://www.hackerthreads.org/phpbb/v...ic.php?p=81054

02-24-2007, 08:28 PM
#35
RaZoR^ is offline RaZoR^
RaZoR^'s Avatar
Status: Member
Join date: Feb 2006
Location:
Expertise:
Software:
 
Posts: 191
iTrader: 1 / 100%
 

RaZoR^ is on a distinguished road

  Old

I said that the random salt is stored somewhere; I made a point of saying it's usually stored alongside the hash in the database.

The hash can't be changed in a set-time process. As you said yourself just now, you would have to ask each user to reset (or just re-enter) their password the next time they login, use the old salt to make the hash and match it against the hash in the database, then use the new salt to make the new hash. I use the word calculate because that's what you do to generate rainbow tables (use the hash function to 'calculate' the hashes of plaintext strings). And yes, you do have to trust the hosting company, but I haven't seen many companies that I wouldn't trust. But that applies to everything you do with your site.

Many of the sites I see do simply store hashes in cookies and then match them against the hash in the database. This seems to be decreasing luckily but still exists in some publically available systems.

I pointed out that if the salt is discovered in a static salt situation, that you are then left with only an extremely slightly slower program to find the original plaintext password, as it's not difficult to make a program that prefixes all the passwords in a brute-force or dictionary attack.

And my point was that either methods are good. The static salt must first be discovered. More often than not, security is compromised on sites and the attacker is left with only access to the database, whereas they won't have the salt which is hard-coded into the PHP file. It's a matter of choice.

Closed Thread  
Page 4 of 4 < 1 2 3 4


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes

  Posting Rules  
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump:
 
  Contains New Posts Forum Contains New Posts   Contains No New Posts Forum Contains No New Posts   A Closed Forum Forum is Closed