-3

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

Andrei Botalov
  • 5,267
  • 10
  • 45
  • 73
Tar
  • 347
  • 1
  • 4
  • 7
  • 8
    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 – Andrei Botalov Jul 12 '12 at 13:16
  • 2
    @AndreyBotalov What the OP described IS encryption, as his solution is reversible. Ramhound is correct. –  Jul 12 '12 at 13:22
  • 1
    @TerryChia his part of solution before bcrypt can be said as cipher but very weak. But overall soltuion (with bcrypt) can't be reversed. – Andrei Botalov Jul 12 '12 at 13:26
  • Well, this question is asking about the validity of his custom solution, so I'm not taking account into the bcrypt portion. Like the answers suggest though, there isn't any point to doing it, and it might even weaken the hash. –  Jul 12 '12 at 13:28
  • 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
  • That isn't really different from using a salt. As long as you salt and using some hash that isn't 10k guesses per second you're fine. (although i'm unsure how many guesses per second is ideal) –  Jul 13 '12 at 01:28

6 Answers6

10

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.

David Schwartz
  • 4,203
  • 24
  • 21
3

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!

Cyril N.
  • 2,649
  • 2
  • 18
  • 28
3

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.

martinstoeckli
  • 5,149
  • 2
  • 27
  • 32
3

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.

CodeExpress
  • 2,422
  • 13
  • 10
3

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.

Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
1

The short answer is NO.

NEVER EVER MAKE YOUR OWN HASHING ALGORITHM!

Home cooking algorithms for hashing are never ever secure and therefore a very bad idea. It's also a bad idea to mix two algorithms together as it can make things even more insecure.

There are many other algorithms out there that you could use. You can use Bcrypt, Scrypt, sha2, sha512 , PBKDF2 and many more.

These algorithms have been tested and made for years and there is not many flaws that have been found with it yet and are made of many security professionals who knows exactly what they are doing.

I would recommend you to use the PBKDF2 or bcrypt algorithms to store your passwords.

Take a look here why I recommend that:

Do any security experts recommend bcrypt for password storage?

Community
  • 1
Arnar Freyr
  • 146
  • 4