password is hashed?

[markart]

I wanted to say that I really enjoyed this tutorial http://www.vbdotnetforums.com/windo...ven-login-form-admin-backend-image-heavy.html . As for my own personal experience with databases, well I hate em. Just kidding.

I followed all of your steps in part 1 and 2, but have some questions or concerns that I am hoping you can help answer. I ported the way you did all of the above into my existing application. Coincidentally my application is a username, password and login-url remembering system that uses its own database. Works fine but basically unprotected.

I had to create a new database called Users (like yours) in order to get my login to work using your methods, as right now this is my only defense. So my question basically resolves around the fact that naturally I wouldn't be able to log in normally once the User password is hashed. So how do I log into my application?


I could elaborate further if you don't quite understand what I am asking for here.
But best regards.

 

[Herman]

The "shadowed" password technique works such that you never have to store or transmit the password in plain text anywhere for security purposes. You "hash" a bunch of private information into a cipher (usually with some sort of time data; adding the current date to the mix would create a cipher only good for a day for example) using a one-way algorithm like MD5 or SHA, and store the cipher instead. So when the user enters his information, it is hashed by the client, sent to the server, the server in turn hashes its own private encrypted copy of your information and compares. If the hashes are the same, then necessarily the username and password entered was the same.

A simple example:

Start with a value A of 80.
Let's say the hashing algorithm here adds 10.
Send 90 to the server.
Server receives 90, takes its private encrypted copy of 80, adds 10, and compares.
Since 90 = 90, access is granted, without ever having to transmit 80 over an unsecured channel.

The way you setup "encryption" here is useless, because anyone who gains access to the machine running the database server will be able to read the password in plain text (yes, even the hash is plain text!). The idea is to not store the password at all!

 

[markart]

@Herman, many thanks for replying to the continuation of my above reply.

Sure, I'd rather not store the password to login to the application at all. Following formlesstree4's tutorial above proved useful. Of course my applications backend shows the main user all of the urls, passwords and usernames to log into url pages that they visit online (makes for a unique time-saving app). This assumes however that the "main user" of my app is primarily the only one that uses his/ her machine. So the application is not meant to be server-based, nor an internet application, it just stores important user information in one of its' databases.

I'm still looking for a way to login to my application once the password has been hashed. Because using the same password into the login just says that it is the wrong login password. In other words I cannot login with my password once it has been hashed. So I'm wondering if there is a method to this madness (so to speak), so that I can login using the original password even though it has been hashed with encryption?

 

[Herman]

If the database is local, or you are using the Windows user accounts, then I would suggest not reinventing the wheel and using SQL Server's integrated security. The reason I don't recommend using standard SQL security over a network is because the usernames and passwords are transmitted in plain text by default and can be vulnerable to a man-in-the-middle attack. Using NT security, or running the queries through SSL fixes this, but is not always possible.

If it is just a proof of concept, try using an encrypted stored procedure with a strong private key to decrypt a password encrypted in your application with a public key. SQL Server already has provision for this through the CREATE ... KEY statements. In this case, your application uses an "unsafe" public key (because it is assumed a moderately skilled attacker could gain access to it) to encrypt the password the user enters. This produces a cipher text that you send to the server by calling your stored procedure. Because of the way the algorithm works, ONLY the private key can decrypt the ciphertext. The stored SQL procedure is encrypted into the database (this one is considered as safe because only someone with superuser privileges over the SQL instance can access it), and contains the private key. When you call it it uses the private key to decrypt the password you previously encrypted with the public key in your application, and execute whatever query you want.

Example:

CREATE ASYMMETRIC KEY akey WITH ALGORITHM = RSA_2048 

ENCRYPTION BY PASSWORD = 'aaa123'
GO
CREATE SYMMETRIC KEY skey WITH ALGORITHM = AES_256 ENCRYPTION BY ASYMMETRIC KEY akey
GO

DECLARE @t TABLE(plain VARCHAR(100), ciphered VARBINARY(MAX), unciphered VARCHAR(100))

INSERT @t(plain)
VALUES('11111'), ('22222'), ('33333')

OPEN SYMMETRIC KEY skey DECRYPTION BY ASYMMETRIC KEY akey WITH PASSWORD = 'aaa123'

UPDATE @t SET Ciphered = ENCRYPTBYKEY(KEY_GUID('skey'), plain)
CLOSE SYMMETRIC KEY skey

DECLARE @open nvarchar(200), @close nvarchar(200), @password VARCHAR(20) = 'aaa123x'
SET @open = 'OPEN SYMMETRIC KEY skey DECRYPTION BY ASYMMETRIC KEY akey WITH PASSWORD = ' + quotename(@password,'''') + ';';
SET @close = 'CLOSE SYMMETRIC KEY skey;';
BEGIN TRY 
  EXEC sp_executesql @open
  UPDATE @t SET unciphered = CAST(DECRYPTBYKEY(ciphered) AS VARCHAR)
  SELECT * FROM @t
  EXEC sp_executesql @close
END TRY BEGIN CATCH 
  SELECT 'Do whatever you want to do here with this caller. Suspicious caller: '+SUSER_SNAME()+', at: '+CAST(GETDATE() AS VARCHAR)
END CATCH

DROP SYMMETRIC KEY skey
DROP ASYMMETRIC KEY akey