objective c - Password Verification - How to securely check if entered password is correct -


i'm developing app requires multiple passwords access varying data areas. example, group of people set chat requires password authentication view.

here's how i'm considering doing it:

i have keyword, let's hypothetically:

banana

when user enters password, use rncryptor encrypt banana using entered key, , store encrypted string server.

later, when tries enter password, take hashed value server , try decrypt using password entered key. if decrypted value equals banana know entered correct password.

i'm new security, i'm not sure if appropriate solution. appreciated.

update

after making alterations suggested @greg , aptly named @anti-weakpasswords, here's have:

- (nsdictionary *) getpassworddictionaryforpassword:(nsstring *)password {      nsdata * salt = [self generatesalt256];     nsdata * key = [rncryptor keyforpassword:password salt:salt settings:mysettings];      nsmutabledictionary * passworddictionary = [nsmutabledictionary new];      nsstring * saltstring = stringfromdata(salt);     nsstring * keystring = stringfromdata(key);      passworddictionary[@"key"] = keystring;     passworddictionary[@"salt"] = saltstring;     passworddictionary[@"version"] = @"1.0.0";     passworddictionary[@"iterationcount"] = @"10000";      return passworddictionary; }  static const rncryptorkeyderivationsettings mysettings = {     .keysize = kcckeysizeaes256,     .saltsize = 32,     .pbkdfalgorithm = kccpbkdf2,     .prf = kccprfhmacalgsha1,     .rounds = 10000 };  - (nsdata *)generatesalt256 {     unsigned char salt[32];     (int i=0; i<32; i++) {         salt[i] = (unsigned char)arc4random();     }     nsdata * datasalt = [nsdata datawithbytes:salt length:sizeof(salt)];     return datasalt; } 

  • do not use single pass of hashing function store passwords.
  • do not fail use random salt in 8-16 byte range.
  • do not use reversible encryption store passwords.
  • do not use password precisely entered encryption key.

instead, when user selecting keyword/passphrase

  • generate cryptographically random 8-16 byte salt
  • use pbkdf2, bcrypt, or scrypt said salt , large iteration count/work factor processors can handle create password hash
    • if use pbkdf2 in specific, not request larger output native hash size (sha-1 = 20 bytes, sha-256 32 bytes, sha-384 48 bytes, , sha-512 64 bytes), or increase comparative advantage attacker has on you, defender.

then in database, store user's particular:

  • salt in clear
  • iteration count/work factor
    • so can change/upgrade later
  • resulting password hash
  • version of authentication protocol - 2, probably, or 1.
    • so can change/upgrade later if move method newwellknownmethod later

when user wants authenticate system, you:

  • retrieve version, salt, iteration count/work factor, , resulting hash database
  • hash whatever keyword/password entered salt , iteration count/work factor database.
  • compare result got in database; if they're same, let them in.
    • advanced: use constant time compare, doesn't quit trying if first byte different, reduce vulnerability timing attacks.

please read how securely hash passwords?, of thomas porrin's answer commonly referred stackexchange treatise on password hashing, , best i've seen far.


Comments

Popular posts from this blog

java - WrongTypeOfReturnValue exception thrown when unit testing using mockito -

php - Magento - Deleted Base url key -

android - How to disable Button if EditText is empty ? -