Password security -

currently using particular scheme securing passwords, , think have points improvement. implementation in java, prefer use sha-2 512 encryption form.

currently have client-server model, these things can happen:

• client wants login, sends password 1 time normal sha-2 512 encryption on network.
• the server has passwords stored in database example sha-2_512(sha-2_512(password) + salt), inner sha-2_512(password) being 'encrypted' password receives on network.
• password checks done server side , there no way can leak out server, possible vulnerability if read out ram think.

i have these questions:

• an attacker creates collision attacks when wanting hack password. how collision attacks sufficient? if password needs used other applications outlook.com, facebook or whatever (which use salt have nothing applications), how collision attack enough then? don't need real password?

• does sha-2 512 use iteration? , if so, should change encryption methods automatically use number of iterations plus how many iterations preferred? have read using random number of iterations (in range), how store random factor determenistically?

• should store system secrets every iteration in server code? see http://blog.mozilla.org/webappsec/2011/05/10/sha-512-w-per-user-salts-is-not-enough/ . store array hold static secret every iteration, nth secret being nth iteration. nobody can know secrets, computed once (i guess encrypting random string), , stored in server's ram.

• currently send typed password client server sha-2_512(password), should process improved, , if so, how? cannot use salts, because client not have salt available.

regards.

tldr: need send password using encrypted channel, such tls. consider using bcrypt password hashing.

sha-2 512 not encryption algortihm, message digest algorithm. encryption algorithm requires key , message encrypt. produces ciphertext. important thing encryption algorithm has decryption algorithm.

ciphertext = e(key, plaintext); plaintext = d(key, ciphertext); 

a message digest takes piece of plaintext , produces message digest. there no corresponding reverse mechanism take message digest , retrieve original message. there no secret key.

digest = hash(plaintext); 

if attacker able access database hashes, attacker can retrieve original password brute forcing, trying lots of guesses hash algorithm.

digest1 = hash(guess1); digest2 = hash(guess2);    //repeat lots of guesses 

firstly, sending hash on network not secure. needs sent through secure communications mechanism such ssl. if attacker can intercept hash on communications may able work out orignal password.

a hash collision not same brute forcing password. hash collision caused when 2 different messages produce same message digest.

digest1 = hash(plaintext1); digest2 = hash(plaintext2); if ( ( plaintext1 != plaintext2 ) && ( digest1 == digest2 ) )       // hash collision 

sha-512 not have iterations designed prevent brute-forcing. sha set of algorithms designed efficient. reason adding iterations when hashing passwords increase time takes brute force password. idea being cost perform legitimate login attempt , perform 100 iterations tiny compared attacker has millions of passwords, each of requires 100 iterations. adding more iterations helps reduce impact of improved processor speeds (which attacker try more iterations quicker).

you should make number of iterations configurable limit stored against each user. store password hash, salt , iteration count each user. means in future can increase number of iterations take account increased hardware power.

sending sha-2 512 in plaintext not secure. should send within encrypted channel, such ssl.

having said that, sha-2 not designed password hashing algorithm. designed message validation , efficient. consider using purpose built password hashing algorithm. 1 example bcrypt. designed computationally difficult , has salt , iterations built in.