Post reply

Password Encryption

  • August 13, 2009 at 1:50 am

    #224748

    Hi,

    I have a table in which the usernames and Passwords are stored.But the Passwords are not in encrypted format.So anybody who has access to these tables can apparently see these passwords.Can somebody please suggest which is the best method for encrypting the password.Should it be from the backend? Any links to the same would be helpful..

    PS:The front end is using Excel with embedded VB code

  • August 14, 2009 at 1:03 am

    #1039171

    I have the same problem too. Let me know if you get it sorted

  • August 21, 2009 at 6:22 pm

    #1043207

    You shouldn't be storing passwords using an algorithm which allows for the encryption to be reversed (for the passwords to be decrypted). Rather, you should be using a hash function. When a password is entered by the user, it should be immediately hashed and the hashes compared to see if there's a match.

    As to where to do this? Usually it depends. However, since we're talking about Excel as a front end, you probably want to look to do it on the SQL Server. You can use the HASHBYTES() function for this.

    K. Brian Kelley
    @kbriankelley

  • August 25, 2009 at 7:22 am

    #1044150

    I agree with Brian. You typically want to hash the password, then when the user enters his password, you hash it and compare the hashes. If they match, the correct password was entered.

    Note that hash can't be entered as you'll hash it when you compare passwords and a new value is generated.

  • August 25, 2009 at 9:24 am

    #1044274

    Hi,

    Please help in clearifying following doubts:-

    1. Is there is any function to decrpyt the string value encrypted using the hashbytes fuction?

    2. Hashing algorithms are only used to encrypt the data. Later the data encrypted can be verified by comparing the earlier encrypted data and by encrypting supplied data?

    Thanks,

    Ankur

  • August 25, 2009 at 9:42 am

    #1044301

    The hash should be one way. I'm not going to commit that it cannot be decrypted, especially if the length is known. There are rainbow tables to help here, but it ought to be fairly secure.

    2. Yes

  • August 25, 2009 at 11:38 am

    #1044378

    For #1, yes, via brute force for sure. While it is theoretically possible that a decryption algorithm may be found, usually it's typical for researchers to instead focus on finding collisions (where two different values lead to the same hash) or to pre-gen hash values by taking know strings, running then through the hashing algorithm and then storing the original value and the hash, then doing a look up on the hash. Those are rainbow tables, as Steve was mentioning.

    K. Brian Kelley
    @kbriankelley

  • August 26, 2009 at 8:06 am

    #1044881

    Thanks Mr. Steve Jones and Mr. K. Brian kelly for your valuable responses.

    Can you please explain more about Rainbow tables? This is the first time i have heared of it.

    Ankur:-)

  • August 26, 2009 at 8:46 am

    #1044917

    ankur_libra (8/26/2009)

    Thanks Mr. Steve Jones and Mr. K. Brian kelly for your valuable responses.

    Can you please explain more about Rainbow tables? This is the first time i have heared of it.

    Ankur:-)

    Wikipedia: Rainbow Tables

    Project Rainbow Crack[/url]

    K. Brian Kelley
    @kbriankelley

  • August 26, 2009 at 8:51 am

    #1044925

    That's what I was going to post 🙂

    Basically a lookup. Find the hash, look up the possible plaintext(s)

  • August 28, 2009 at 5:21 am

    #1046113

    Thanks for the replies.

    It's really nice and learning to be part of such a fantastic group.

    SQL Central rocks!!

    Ankur 😛

Viewing 11 posts - 1 through 10 (of 10 total)

You must be logged in to reply to this topic. Login to reply