In my application I am sending password to database,lets say my Password is PassworD123.
Now this is giving me proper value ,but when i am using password123..its also giving me the proper value.So how to chaeck for case sensitive data in SQL server.
Any demo code will help.
Thanks.
Why not use encryption to store the passwords in the database such as md5 because they will return different hashed versions for example
Md5 of password123 = 482c811da5d5b4bc6d497ffa98491e38
Md5 of PassworD123 = bbac8ba35cdef1b1e6c40f82ff8002ea
and when you compare them 2 they are clearly different.
I think you are using ASP therefore i dont know if it has an md5() function built in but php does have it. Another thing you should know is that if you are storing passwords in a database its better to store them using some sort of encryption that cannot be reversed
You can use COLLATE clause in your T-SQL statement.
Ex.
SELECT * FROM dbo.TableName WHERE Password = # password COLLATE SQL_Latin1_General_CP1_CS_AS
The immediate answer to your query is here:
http://web.archive.org/web/20080811231016/http://sqlserver2000.databases.aspfaq.com:80/how-can-i-make-my-sql-queries-case-sensitive.html
However I think your approach to storing / comparing passwords is a bit wrong. You should not be storing the password directly in the database. At-least MD5 it or something.
Well, the short answer is to use a case-sensitive collation - the longer answer is don't store plaintext passwords in your database!
Related
I have read a lot about hashing and salting passwords. I know how hashing works, that is all very easy, but the thing I am confused about is salting.
If I hash and salt a password and stick it into the database, how can I check that password with the password given when a user tries to log-in. Surely because the salt is completely random, it will be near-impossible to get that salt again to be able to match the database
EXAMPLE:
//On create account.
hash(password + randomSalt) to the Database
//On log-in
hash(password + differentRandomSalt) compare to Database
You generate a random hash of a fixed length with every password you hash. Then you store that salt in combination with the computed hash into one database column.
When the user wants to login, you extract the salt-part from the database and can match the results.
Example:
var salt = GenerateSecureRandom(16) // generates e.g. 0x42552241
var saltedHash = Hash(salt + password)
Login scenario:
var saltedHash = GetSaltedHashFromDatabase()
var salt = GetFirstBytes(saltedHash) // 0x42552241
var hash = GetRemainingBytes(saltedHash) // 0x47111337
var match = IsMatch(hash, salt, userInput)
A database entry could look like this (where = is the salt and * is the hash):
0x4255224147111337
========********
For (much) more details have a look at: https://crackstation.net/hashing-security.htm
The salt is random for each different user/password combination. It's not random for the same user/password combination. If that would be the case, then you would not be able to verify the password, as you already found out. If a large enough salt is generated with a sufficiently secure random number generator then it would even be impossible to verify the password. The idea of the salt is to protect against rainbow table attacks as well as creating a different password hash for different users if the password is the same.
The salt is usually stored together with the username and password hash in the database. It could be made part of a special construct that contains the salt and the password hash or it could be stored in a separate column. Sometimes the password-hash is actually a special string containing both the salt and the hash in some kind of format (using hexadecimal or base64 encoding) that needs to be parsed, but it could also a binary value simply consisting of a statically sized salt and statically sized hash.
An example bcrypt string would be:
$2a$12$QyrjMQfjgGIb4ymtdKQXIewDBqhA3eNppF8qOrMhidnEbzNvmHqhy
which is constructed as in this SO answer.
Setup:
find user
receive & verify old + password (see below)
receive new password
generate random salt
calculate hash from password and salt
store salt & hash in database with user
Verification:
find user
receive password
retrieve salt & hash for user
calculate hash to verify from password and salt
compare and return result
Usually, for security reasons, you should try and do a time-constant compare, even if that's not really an issue for password hashing. Furthermore often no distinction is made between unknown user and wrong password, simply to avoid giving information to attackers.
It makes sense to construct your password hashing scheme in such a way that it allows for updates to the amount of iterations, hash size, hash function etc.
My problem is a bit hairy, and I may be asking the wrong questions, so please bear with me...
I have a legacy MySQL database which stores the user passwords & salts for a membership system. Both of these values have been hashed using the Ruby framework - roughly like this:
hashedsalt =
Digest::SHA1.hexdigest("--#{Time.now.to_s}--#{login}--")
hashedpassword =
Digest::SHA1.hexdigest("#{hashedsalt}:#{password}")
So both values are stored as 40-character strings (varchar(40)) in MySQL.
Now I need to import all of these users into the ASP.NET membership framework for a new web site, which uses a SQL Server database. It is my understanding that the the way I have ASP.NET membership configured, the user passwords and salts are also stored in the membership database (in table aspnet_Membership) as SHA1 hashes, which are then Base64 encoded (see here for details) and stored as nvarchar(128) data.
But from the length of the Base64 encoded strings that are stored (28 characters) it seems that the SHA1 hashes that ASP.NET membership generates are only 20 characters long, rather than 40. From some other reading I have been doing I am thinking this has to do with the number of bits per character/character set/encoding or something related.
So is there some way to convert the 40-character SHA1 hashes to 20-character hashes which I can then transfer to the new ASP.NET membership data table? I'm pretty familiar with ASP.NET membership by now but I feel like I'm just missing this one piece. However, it may also be known that SHA1 in Ruby and SHA1 in .NET are incompatible, so I'm fighting a losing battle...
Thanks in advance for any insight.
The varchar representation in your Ruby app appears to be 'hex as string', something like this: 01AB02EF...23EF. that is, each byte is represented as a pair of characters that are the hex value of the byte, from 00 to FF. Therefore the SHA hash (20 bytes) is represented as 40 characters. IF the hash is the values (0, 1, 2, ...) the string will be 000102. The ASP base64 is the base64 encoding of the actual bytes. So all you need to do is take the MySQL characters and obtain the corresponding bytes, then encode them as base64.
You can actually do the transformation in SQL itself:
declare #x varchar(40);
set #x = '000102030405060708090A0B0C0D0E0F10111213';
declare #sql nvarchar(max);
set #sql = N'set #out=0x' + #x;
declare #out varbinary(20);
exec sp_executesql #sql, N'#out varbinary(20) output', #out output;
select #out for xml path('');
But to coerce your ASP.Net membership provider to use the salted hash your Ruby code created, irrelevant of the encoding used to store the hash digest, that's a whole different topic. You'll likely have to rewrite your own membership provider, at which point the storage encoding becomes irrelevant, since you can store them as you wish.
Ruby uses SHA2, and ASP.NET uses SHA1, and no, you can't 'convert' between those versions. For that you'd need to recalculate the hashes from the plaintext.
Edit: SHA is standarlized, so you can search in the internet for a SHA2 library to use in ASP.NET.
I is there a way to add "additional info" to a sqlite database. Something like date of creation of a database, amount of entries or name of user who created it. If I don't want to create special tables in order to store all this info especially if there will only be one of each type.
Thank you in advance.
Why not use one special table and store each special value as a name-value pair?
CREATE TABLE SpecialInfoKeyValues (
Key VARCHAR UNIQUE COLLATE NOCASE,
Value
);
Since SQLite uses "manifest typing," you can store any kind of value you want in there.
In short, no. SQLite has no concept of users, and doesn't store creation metadata.
No, there is no way to do that, you will have to use a "special" table to carry data within the file, or you will have to use external means.
There are, however, two version counters stored within the database itself: the schema_version and the user_version (see Pragmas to query/modify version values for details.) Perhaps you could abuse those. Please keep in mind, though, that by default the sqlite3 shell application does not store those when you use the .dump command to dump the database into a textual representation.
I'm wondering if it's possible for me to get the QuestionAnswer field from ASP.NET membership in the same way that you can get the UserName and PasswordQuestion.
MembershipUser mu = Membership.GetUser(userId);
string username = mu.UserName;
string question = mu.PasswordQuestion;
I'm pretty certain that the QuestionAnswer is hashed in the database in the same way that the password is. If that is the case then you won't be able to get the QuestionAnswer in any sort of human-readable format (although if you require the QuestionAnswer in this format you can always run a regular SQL query against the table rather than using the Membership API).
If needed you can always change the password question and answer
Hope this helps.
I need to compare the answer in with the aspnet_membership tables PasswordAnswer value.
The text in Password answer is in the form of Hashed. What algorithm they have used how they implemented the Salt value in ASP.net Membership Provider.
I have tried hashing (sh1) and compared with text what is salt value
How to hash my answer value.
string answer = "one";
string hashedvalue = "dfdsfsdfdsfdsfdfdf";
I need to compare this both.
I have converted the answer to hashed format. But both are different> I think due to salt value. How can I utilize this.
You should be using the Membership class' ValidateUser method to do this.