3

I need to encrypt an NSString before sending to a WebAPI. What are the best practices for this? I've been looking at different articles but haven't found what I'm looking for. The whole hash/salt with date thing seems like the best approach as of this writing. ANyone know how to do this in iOS? Then, do I just store it in the DB as varchar(50)? And for subsequent logins just do a text compare? Thanks all.

Beau D'Amore
  • 3,174
  • 5
  • 24
  • 56

1 Answers1

2

  1. Encrypt and authenticate the connection to the server with HTTPS. This counteracts eavesdropping and MITM attacks. Be sure to verify server certificates on the client side.

  2. On the server, hash the password with a randomly generated salt.

  3. Store the hash and the salt in a database. Yes, you can use something like a text or varchar(50) to store the hash and salt.

This has been covered in a few other questions before: see Best way to store password in database

Community
  • 1
  • 1
Dietrich Epp
  • 205,541
  • 37
  • 345
  • 415
  • I would rather hash it in iOS before sending to the server and simply store is server-side. The server can just compare the hashed pw login attempts. Happen to have some sample code for encryption in iOS? – Beau D'Amore Nov 04 '13 at 16:48
  • @Beau: If you do it that way, a database compromise will mean that all of the user accounts are immediately compromised, with no work by the attacker. – Dietrich Epp Nov 04 '13 at 23:06
  • That doesn't make sense...how so? if it's hashed before being sent and then stored hashed.. how does the attacker get the pw's "with no work"? It's already hashed so it's being stored the same way if its hashed server side or client side... – Beau D'Amore Jun 17 '15 at 20:01
  • 1
    @Beau: Because anybody can change the client code. Let's say your password is "pass123" and its hash is "DEADBEEF". If the server is compromised, I can then log in as you by sending DEADBEEF. It doesn't matter that I don't know the password, because I do know the hash, and in this scheme I only need to know the hash not the password. Or, put another way, under this scheme, the hash *is* the password, and you are storing it in plain text without hashing. – Dietrich Epp Jun 18 '15 at 05:57
  • gotcha... we we're on two different pages. I understand what you mean. I left out that all DB fields are encrypted, my bad. – Beau D'Amore Jun 18 '15 at 12:33
  • 2
    @Beau: Encrypting DB fields is risky. Hashing the passwords server-side, with a proper KDF and random salt, mitigates this particular risk much better. See: https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet – Dietrich Epp Jun 18 '15 at 16:31