Does shuffling a hashed password increase its security?

Gpoy Gwapo
  • Does shuffling a hashed password increase its security? Gpoy Gwapo

    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.

  • 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.

Related questions and answers
  • I'm making an auth service so I've been looking for some good Java/Groovy implementations of password + salt hashing. I've found this article on crackstation along with a code example and decided...). One thing however kind of struck me. The result string is "[iterations]:[salt as hex]:[hash as hex]". Why are iterations added to the result? Wouldn't that be insecure? Wouldn't that be akin to giving away a piece of the key? Or am I just too paranoid. I have removed it, but I'm wondering why is it there? What is the purpose of showing that? In case the default number of iterations changes

  • I'm afraid I'll have tomatoes thrown at me for asking this old question, but here goes. After reading that cooking up your own password hash out of existing hashing functions is dangerous over and over again I still don't understand the logic. Here are some examples: md5(md5(salt) + bcrypt(password)) scrypt(bcrypt(password + salt)) sha1(md5(scrypt(password + md5(salt)))) The typical... to re-hash standardly hashed passwords into these wacky hashes as they see fit and weaken the hash? I don't buy it. Second argument: Kerckoffs's principle: A cryptosystem should be secure even

  • I may be wrong here but reading about salt I was wondering whether if we use the same salt for every password saved in our database won't users having same password would lead to same hash even after adding salt, hence diminishing the sole purpose of adding salt. If it is true should we only use random salt to the databases? And what should be an optimal salt length? Could someone also explain how is the salt decided, whether it is a pre agreed data that is added only through the code or is it saved somewhere from where it is accessed again and again for each and every password.

  • So, reading through this article: http://crackstation.net/hashing-security.htm it says that storing the salt is fine in plain text because it renders the lookup/rainbow tables ineffective. I get that, but why not generate the salt from the submitted password and then never store that separately either? Something like this: <?php $pass = '12345'; $salt = ''; // generate the salt somehow... probably not like this $hash1 = hash('md2',$pass); $hash2 = hash('md4',$pass); for($i = 0; $i < strlen($hash1); $i += 2){ $salt .= $hash1{$i} | $hash2{$i}; } // hash the results $hashedPass = hash

  • this: UpdatusUser:"":"":AAD3B435B51404EEAAD3B435B51404EE:F100FC1DF3A5300A5C265BDC7CD81E39 The hash starting iwth AAD3 and ends with 4EE is just LM hash for blank password and in this case it means that the password is over 14 characters and it cannot be stored as LM hash. The last hash (F100) is the NTLM hash which I would like to see cracked :) ...Nvidia update service has created a local user on several of my boxes. Does anyone know its password? I recon it could possible be leveraged as an entry way for an attacker. Details: wmic

  • I started reading about password hashing recently on multiple sites like this page on crackstation and others, and for what I have understood, I should avoid using hashing algorithms like md5 and sha1 for they are outdated and instead, I should use sha256 with salt. But, after reading this page on the php manual, I noticed that they discourage the use of even sha256 and instead they recommend using the password_hash() functions. I also noticed that most of this articles/pages were written in the interval of 2011-13, so I am not sure of how secure sha256 hashed password with salts are nowadays

  • As mentioned in this wonderful link, the way to get a PBKDF2 Hash of a user given password given a password (of course), a salt (generated Cryptographically Secure Random Number Generator. iteration count (chosen high enough to be secure while balancing your application's usability tolerance) Hash size (length of the hash to be computed) /** * Computes the PBKDF2 hash of a password. * * @param password the password to hash. * @param salt the salt * @param iterations the iteration count (slowness factor) * @param bytes the length

  • Right now, we might do something like password varchar(72), when defining a password column, with for example BCrypt. But there's a lot of folks that don't do this very effectively. Maybe they just put the plaintext, or a single unsalted md5 hash, or some other terrible strategy. But virtually all these offenders still use databases. So why isn't this kind of functionality baked into databases? Something like mypass password('BCrypt:10'), and accessed like INSERT INTO people(name, mypass, other_data) VALUES(?, ?, ?) which would take the plaintext password from the user and pass

  • and password fields on the login.asp page? Or am I making this all up and this code is perfectly secure? ...There's a Classic ASP application at my job that is (I believe) highly vulnerable to SQL injection. I want to prove to management that this code isn't secure, but all I'm able to do is insert "SQLINJ... attack would be on the AccessLogs table itself, because of replace(lstr,"'","''") which "sanitizes" the SQL-Injection attempt and logs it. I KNOW that this code should be ditched and all executable

Data information