Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I have made a custom hashing method to help make my users' passwords more secure if the database will be leaked.

The encryption method is like this:
A method takes an input of 1 character, gets the ASCII value of the character, shifts it a number of bytes one way and a number of bytes the other way, and then returns like $shift_left.$original_char.$shift_right. After this, the entire jumbled string is hashed using BCrypt with a 22 character salt using 16 rounds.

Does this actually make the passwords more difficult to crack? Since a dictionary attack wouldn't work without my hashing method that has led

share|improve this question
6  
Why are you trying to implement your own encryption method when proven methods already exist? It sounds like your method is a great deal less secure, of course your encryption method, isn't even an encryption method. The fact you call it an encryption method worries me, makes me believe you don't understand the difference, which means I wouldn't use any service that implemnts YOUR encryption method. Encryption and Password DO NOT go well together. –  Ramhound Jul 12 '12 at 11:37
1  
@Ramhound what OP described is hashing, not encryption –  Andrey Botalov Jul 12 '12 at 13:16
2  
@AndreyBotalov What the OP described IS encryption, as his solution is reversible. Ramhound is correct. –  Terry Chia Jul 12 '12 at 13:22
    
@TerryChia his part of solution before bcrypt can be said as cipher but very weak. But overall soltuion (with bcrypt) can't be reversed. –  Andrey Botalov Jul 12 '12 at 13:26
1  
@AndreyBotalov = Did you even read my comment? I said exactly that. I used the word "encryption" to point out his method is likely flawed, unproven, and not even an encryption. –  Ramhound Jul 12 '12 at 14:11
show 2 more comments

5 Answers

Keep in mind that if an attacker wants to get access to your password, it will probably succeed.

You are using BCrypt, which is one of the best way to hash password nowadays. But your cooking recipe just before that is, IMO, useless.

Suppose the attacker get the clear text password from bcrypt, all he has to do now, is the opposite of your function :

A method takes an input of 1 character, gets the ASCII value of the character, shifts it a number of bytes one way and a number of bytes the other way, and then returns like $shift_left.$original_char.$shift_right

Just using BCrypt combined with salt+pepper is a great start.

Don't forget that complexity is the ennemy of secure!

share|improve this answer
add comment

If your plan is to keep the specifics of your encryption method secret, no, it won't work and it's a very bad idea. If you don't have the method peer reviewed, you will never be confident that it doesn't lose information and leave the passwords weaker.

For example, your pre-processing might not be as resistant to collisions as you expect it to be, leading to the possibility that an attacker might enter an incorrect password and still match the hash because his password provided the same input to BCrypt. It's very unlikely you could evaluate this risk yourself and have anywhere near the level of confidence you could have if you just took a well-publicized algorithm and used it as is.

You can't both have it subject to the public scrutiny needed to ensure that it is secure and keep it secret from a potential attacker.

share|improve this answer
1  
+1 To bring out the point that collisions are bad because multiple passwords will be accepted as correct –  Shivam Jul 14 '12 at 3:49
add comment

If the attacker has control over database and code, adding scrambled characters will help nothing at all (only a negligible operation more). If he has only the database without code (SQL-Injection), then he will recognize the bcrypt hash and can now brute force with bcrypt, but because of the scrambling there aren't any weak passwords. It's like the scrambled text would be the password to crack, so a dictionary is of no use.

This is security by obscurity, but will be effective as long as the code is not known. You can get the same effect easier, by adding a fix hard coded salt (key), before using bcrypt with the unique salt.

share|improve this answer
add comment

I'll give you the shortest answer: No

Home-cooked hashing schemes are dangerous because if done wrong, they can have high collision rates (by drastically reducing the output address-space). Any operation you do to these 'hashes' thereafter will not add any more security.

share|improve this answer
add comment

Let me make an analogy. Your question is like: if I have a reinforced steel door, does it make it even stronger if I paint it in red ? After all, any burglar would have to get through both the steel door and the layer of paint. And anything red is obviously better.

To further the analogy, your red paint could actually be acidic or hasten corrosion, thus potentially making the door weaker.

So don't do it.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.