1

I am making a web app and I'm now stuck on making the login secure. I'm thinking of adding a salt to a user-inputted password and then hash it. (md5 or sha for example) and then I will reshuffle the results.

eg: 

$salt = "hello";
$password = "password";
$newpassword = md5($salt.$password); //lets assume the result is 1234567890

I will reshuffle the order of the hash like exchanging the first and last character then 3rd and 3rd to the last.

the result will look like:

0284567391

Does this make the password more secure? Please don't suggest some hardcore encryption stuffs. I just need something that will make the passwords secure than just having them encrypted using a cracked hash algorithm.

  • 1
    The short answer is no, this amounts to security by obscurity and adds no real security to your hashes. Also, don't use MD5, SHA or any general purpose hashing function. – Null Nov 29 '12 at 01:19
  • One needs to understand the implications of weaknesses found in hashing algorithms when it comes to protecting hashed passwords. While you could say MD5 is terribly broken, none of the currently feasible attacks on MD5 make cracking a hashed password any easier than it was before. – Null Nov 29 '12 at 01:23
  • @null how about this paper? http://crppit.epfl.ch/documentation/Hash_Function/Examples/Code_Project/Documentation/104.pdf Does it sound feasible? Our presented algorithm allows us to find full MD5 collisions in only minutes on a 3Ghz Pentium4. – Salvador Dali Nov 29 '12 at 01:47
  • @null or may be these? http://www.win.tue.nl/hashclash/rogue-ca/ – Salvador Dali Nov 29 '12 at 01:48
  • @SalvadorDali You don't understand; these are chosen-prefix collision attacks. They are useless when you want to get the original password from a hash. For this, you'd need a preimage attack - which for MD5 is still in the order of 2^123.4, something that would take more than the age of the universe to complete, ie: unfeasible. – Null Nov 29 '12 at 01:51
  • 1
    As others pointed out, you should use BCrypt or another key derivate function. However, you also seem to be unclear on what a salt is. A salt is defined as a random set of bytes of fixed length; *not* a static value! please also read: http://stackoverflow.com/questions/1645161/salt-generation-and-open-source-software/1645190#1645190 – Jacco Nov 29 '12 at 14:24

5 Answers5

11

The "shuffling" you intend is conceptually a kind of encryption: you apply a secret convention on the result. This changes anything to the security only if the convention is indeed kept away from the prying eyes of the attacker -- the attacker who just plundered the database of hashed passwords, and thus had some extensive access to the internals of your server. But the server must know of the shuffling (since it applies it). Therefore, it seems rather improbable that your shuffling is unknown to the attacker. Conclusion: your shuffling is probably not useful.

What would increase security would be to use a proper password-hashing function, which includes a salt in a cryptographically sane way, and is adequately slow (i.e. made very slow through thousands or even millions of iterations). This is called bcrypt. This sort of thing must not be improvised; homegrown schemes are very rarely secure (most are deemed secure by their inventor, but reality has a tendency to be unkind to the dreams of the self-made inventors, especially in highly technical areas where success cannot be tested, in particular cryptography).

Thomas Pornin
  • 322,884
  • 58
  • 787
  • 955
5

To make your password storage safe, you should not use MD5 or any other fast hash algorithm, instead use a key derivation function like BCrypt.

The problem with fast algorithms is, that you can calculate 8 Giga MD5-hashes per second with common hardware (in 2012). That makes it possible to brute-force a whole english dictionary with about 500000 words, in less than a millisecond!

With shuffling the resulting hash-value, you add an additional secret to the hash. This secret will increase security just as long, as it stays secret. As long as the attacker only got access to the database (SQL-injection) it can help, as soon as the attacker gains control over the server (and your code) there is no benefit at all. You could achieve the same easier by adding a pepper to the password before hashing.

BCrypt was especially designed to hash passwords, and is therefore slow (needs some computing time). With a cost factor you can adapt the needed time to future (and therefore faster) hardware.

Using BCrypt can be as easy, as using the MD5 hash function. PHP 5.5 will have it's own functions password_hash() and password_verify() ready, to simplify this task. There is also a compatibility pack for PHP 5.3/5.4 available, downloadable at password_compat.

martinstoeckli
  • 5,189
  • 2
  • 27
  • 32
2

If you're looking for "more secure," you should use Blowfish or similar using the crypt(); function.

Swapping values should make a simple hash like md5 more secure, but assuming someone has already stolen your hashes, who is to say they don't already know that your application swaps characters in the hash? They would then un-shuffle your hashes and break them easily (assuming a hash like sha1 or md5) with an online tool.

tl;dr, use crypt(); instead and pick good algo and salts.

Andrew Templeton
  • 131
  • 4
  • 3
    You really mean bcrypt, a hashing function built on Blowfish (but it isn't really Blowfish, which is a symmetric block cipher). – Null Nov 29 '12 at 01:26
  • Perhaps I am missing something - can crypt not run as blowfish on most machines? (below from php.net) CRYPT_BLOWFISH - Blowfish hashing with a salt as follows: "$2a$", "$2x$" or "$2y$", a two digit cost parameter, "$", and 22 digits from the alphabet "./0-9A-Za-z". – Andrew Templeton Nov 29 '12 at 18:13
  • That's a bit of misnomer. If you pay close attention, the manual goes on to say it's a "Blowfish-based hashing algorithm" – Null Nov 29 '12 at 19:24
1

I'm gonna make this one short and sweet.

First, check this link out: http://crackstation.net/hashing-security.htm

Second, just use PBKDF2/bcrypt and a long salt. You'll be safe with that. Engineering your own type of manipulation, encryption, or hashing is almost never a good idea.

JZeolla
  • 2,966
  • 1
  • 19
  • 25
-4

Why not just use SHA1 or SHA255?

Ian Atkin
  • 101
  • 2
  • -1 Because you should never use a general purpose hashing function like SHA to hash passwords. – Null Nov 29 '12 at 01:16
  • SHA1 has been cracked and i need something more secure than just having it hashed directly. –  Nov 29 '12 at 01:17
  • 1
    Cracked is not really the correct word. But you shouldn't be using SHA-x to hash passwords – Lucas Kauffman Nov 29 '12 at 07:10