57 posts in this topic

Posted

Just another tip, hiding your password creation and verification routines isn't a bad idea.

 

I like to use used an encrypted stored procedure in the database server for logins(In my case MSSQL). You feed it the user name and password, it returns true or false. You can, of course, get more complex, but the design rule was that all logins are validated through the one procedure. You can call it from another proc, from the web server or from any other front end, but that SP was the only way to validate a login.

I can't imagine that being very secure, if somebody attacks your database (Which is pretty much going to be the attack vector) they've then got your custom method for authenticating users.

If the method was properly secure, you could tell the attacker exactly how you're doing it and they still wouldn't be able to break it (Just because the attacker knows you're using bcrypt, doesn't make bcrypt any less secure, etc.)

Share this post


Link to post
Share on other sites

Posted

what about: sha512(sha256(sha256(sha256(<password>) + <username>) + sha256(<password>) + <password-set-date&time>)) ?

Adding user-specific and different types salting would surely make it harder, no?

Share this post


Link to post
Share on other sites

Posted

Not really, you're not adding any actual extra work for the attacker, they still just have to come up with one password to test.

Edit: The hard part isn't "How many times do I run SHA", it's "What do I feed the hash function?", adding 3 hash iterations isn't any harder than just 1 hash iteration, it's just ever so slightly slower.

Share this post


Link to post
Share on other sites

Posted

If you are hashing multiple times, it should be with different salts each time.

Share this post


Link to post
Share on other sites

Posted

I can't imagine that being very secure, if somebody attacks your database (Which is pretty much going to be the attack vector) they've then got your custom method for authenticating users.

If the method was properly secure, you could tell the attacker exactly how you're doing it and they still wouldn't be able to break it (Just because the attacker knows you're using bcrypt, doesn't make bcrypt any less secure, etc.)

 

First off, the production database server doesn't see the Internet. It doesn't even have a default gateway. It's locked down to VPN and local server access only.

Second, The stored procedure is compiled with encryption, it's not easily editable, and they would have to break the database security system to figure out how to decrypt it.

Third, I'm using bcrypt, but it's not on the forward facing server, it's out of sight in a stored procedure with much tighter security.

 

So, after breaking the VPN, breaking domain security, and breaking SQL Server security, they've figured out I'm using bcrypt. 

 

Now, if we coded security at the web tier, someone could break into the public facing server and figure out what we're using in far less time. Why make it easy on them?

Share this post


Link to post
Share on other sites

Posted

If they get access to your web server chances are they'll get access to your database server.

If you think that just because one server itself doesn't have the internet makes it untouchable, you've got a lot to learn. A very early example of netcat was exactly that, hack a web front end, put a netcat remote listener on and then you do what you want to the database server as if it was on the internet.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0

  • Recently Browsing   0 members

    No registered users viewing this page.