May 6, 2012 at 9:10 am
S_Kumar_S (4/24/2012)
It's advisable to have passwords encrypted rather than storing them as it is...
Passwords shouldn't be encrypted, because there is no need to ever decrypt them. They should be stored using a one-way hash, something that's irreversable.
The SQL function to do that is HASH_BYTES, but anyone planning to store passwords should read up on hashing and salted hashes before they start.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
May 6, 2012 at 9:13 am
vahid.arr (4/24/2012)
i have userid pk and i want also make username and password field uniqe.how can i do that?
Requiring passwords be unique is a mistake. It means that a person creating an account can figure out other people's passwords.
If I create an account, try to use 'Password1' as a password and the system tells me that passwords have to be unique, then I know someone's password, and I just have to try the various usernames to figure out which user has that password. Not a good idea.
Unique usernames, yes. Unique passwords, no.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
May 6, 2012 at 9:34 am
I did gasp when I read "Passwords shouldn't be encrypted". However, I needn't have, what I think Gail was saying is that passwords must never be stored in plain text, but be stored in a way that following a matching manipulation can be checked as correct. This could be a Microsoft supplied function or another mathematical function.
Dave
May 6, 2012 at 10:06 am
Dave Brooking (5/6/2012)
I did gasp when I read "Passwords shouldn't be encrypted". However, I needn't have, what I think Gail was saying is that passwords must never be stored in plain text, but be stored in a way that following a matching manipulation can be checked as correct.
Read up on one-way hashes.
Encryption is a bad choice for passwords because there is never a need to decrypt them, and should the encryption key be compromised, all passwords can be retrieved in plain text and that is never a desirable event.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
May 6, 2012 at 10:32 am
Gail,
I do agree that encrypting passwords is not the right way to go. However, I do think that the term encryption can be misused (probably by me as much as anyone). I think I was talking about obfuscation rather than encryption.
Dave
May 6, 2012 at 10:45 am
Dave Brooking (5/6/2012)
I think I was talking about obfuscation rather than encryption.
I certainly wasn't suggesting obfuscating passwords, that's worthless. I'm recommending the use of cryptographic hashes. http://en.wikipedia.org/wiki/Cryptographic_hash_function
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
May 6, 2012 at 10:51 am
visjaaah (5/6/2012)
as far as i can see, unique only applies to nullable columns.
Not at all. A unique constraint can be applied to any column, regardless whether it's nullable or not. If you want a column that does not allow nulls and is unique, you just defined it as NOT NULL, then create a unique constraint on that column.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
May 6, 2012 at 11:06 am
Gail,
Yes you're right.
I'm pretty lazy with my expressions. With English being my first language I should check the real meanings of the expressions I use (especially in an international forum).
Dave
Viewing 8 posts - 16 through 22 (of 22 total)
You must be logged in to reply to this topic. Login to reply