hashcat Forum

Hi Everyone,

As it is supposed that majority here in forum are well aware of hashing, I'd like to ask for your valuable ideas about hashing DataBase credentials. We're planning to launch an automated system of credit purchase for 3rd party VoIP services.

Some may argue that 'Well, you know, security doesn't only mean protecting DB' and etc. Of course, we're also working on other matters regarding the web-site protection as a whole. But this thread is about one of its components - protecting DB.

Please, help with your unique ideas and experience to make a reliable solution, preferably something that at least can be used for another couple of years, taking into consideration the on going development of hash cracking tools and methods, so that all information which can be sensitive in case of DB dump, should be well protected.

As it's said - 'A danger foreseen is half avoided'.

In addition, we are ready to sacrifice and accept a reasonable performance drop-down for this sake.

Thanking you all in advance.

PBKDF2 with another column or table containing a randomly generated long salt would be quite effective IMHO

(06-14-2012, 04:36 PM)blazer Wrote: [ -> ]PBKDF2 with another column or table containing a randomly generated long salt would be quite effective IMHO

Thanks for your input. How long do you think will be effective?

I'm also concerned whether hashing (with good salt) other credentials like username, access rights, registered date can give effect. This is why I've created a poll too. Because there are some people, who advise to hash/salt them also, for the following reasons - some other plaintext information may help the intruder to single out users with privileged rights and to focus exclusive on them, rather then the whole DB dump. It will save time and by this way he will possibly get the result faster. Even registration date and/or authorization logs (by analyzing the frequency and duration) can help to exclude regular users.

The question is to what extend it is justified, and how severe it may harm the performance and reliability.

hashed with a salt is all you need provided 1. you use a password hashing algorithm and not a cryptographic hashing algorithm, and 2. you use a unique, randomly generated salt for each hash in your database.

the rest is just goofy imo.

Like others mentioned. Unique salts per user AND highly iterated hashing algorithm AND possibly enforcing a minimum complexity to password like > 8 chars, containing at least 1 symbol, etc.

Thanks for everyone for comments.

Is there any idea how severe the iteration alone may effect and slow the processes (e.g. brute-force speed and site's performance) and what may be the reasonable number of iteration for good security? For example, in case of scrypt, bcrypt or PBKDF2?

you should test by yourself how many iterations your server can bear. There will always be a trade off between security and performance.