HMACKey

[Chris]

Hi,

sorry, I know it might be (if it not: is) a stupid question, but how are we supposed to use the HMAC?

Suppose our users tend to use a weak password (say, a 4 digit pin), what is best practice for message-transportation-level security with server validation?

Currently we're doing C/R by sending random bytes as a challenge which gets encrypted/signed/hashed (whatever it's called - sorry) using the "session password" via CCHmac by the receiver(slave) and that is sent back to the "master".  Master compares plain challenge with response, thus validating the slaves identity (identity = using correct password).

Afterwards we're using the same password for encrypting every message from master to slave via

+ (NSData *)encryptData:(NSData *)thePlaintext withSettings:(RNCryptorSettings)theSettings password:(NSString *)aPassword error:(NSError **)anError

Given users tend to use weak passwords like 4 digit pins, would that be strong enough? Or could we add some extra level of security by using a second password* as salt?

If this is the case, as far as I know, we could use

+ (NSData *)encryptData:(NSData *)thePlaintext withSettings:(RNCryptorSettings)theSettings encryptionKey:(NSData *)anEncryptionKey HMACKey:(NSData *)anHMACKey error:(NSError **)anError 

where encryption key is created with session password and second password - right? But then HMACKey would be nil. If we'd use our hmac as HMACKey and create the encryption key from plain password via

+ (NSData *)keyForPassword:(NSString *)password salt:(NSData *)salt settings:(RNCryptorKeyDerivationSettings)keySettings;

what should we use as salt if not the second password?

Phew, sorry, but I got really lost on the track, trying to get used to all the crypto stuff

* second password could be dynamically created from usernames or ids of both master and slave

[Rob Napier]

First, as a general rule, you shouldn't be using the HMAC directly. Consider it an internal implementation detail. Unless you really know what you're doing, you should be using the password-based methods.

I don't understand why CCHmac is involved here for auth. If the user doesn't have the right password, then the encryptData: will generate something the server can't decrypt, so you shouldn't particularly need a different step to authenticate the user.

You definitely shouldn't (and can't) pass nil as the HMACKey. That has absolutely nothing to do with how you're using CCHmac. The HMACKey is used to make sure that the encrypted message is not modified in transit. There's no reason (and you shouldn't) use your own HMAC key for that. Though I'm not clear what your "session password" is. Do you mean the PIN? (Usually you wouldn't call a PIN a session password.)

4-digit PINs stink. There are only 10k of them, and users generally pick out of a small subset of those. The only way to make PINs reasonably secure is by locking the account if someone guesses too many of the wrong PIN. Scaling how many guesses and how to remove the lock depends on your situation.

This list is ideal for addressing issues specific to RNCryptor, but if you need more in-depth security consulting services to help you design an authentication and encryption system, feel free to contact me directly.

-Rob

--
You received this message because you are subscribed to the Google Groups "rncryptor" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rncryptor+...@googlegroups.com.
Visit this group at https://groups.google.com/group/rncryptor.
For more options, visit https://groups.google.com/d/optout.

--

Rob Napier
Cocoaphony blog -- http://robnapier.net/blog

iOS Programming Pushing the Limits -- http://robnapier.net/book