rfc:improve_hash_hkdf_pramater

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
Next revisionBoth sides next revision
rfc:improve_hash_hkdf_pramater [2017/02/05 03:55] – yohgakirfc:improve_hash_hkdf_pramater [2017/02/05 06:30] – yohgaki
Line 98: Line 98:
   - Get the secret password hash generated by hash_password() for the user.   $ikm   - Get the secret password hash generated by hash_password() for the user.   $ikm
   - Get application secret salt stored in secure place. e.g. $_ENV   $salt   - Get application secret salt stored in secure place. e.g. $_ENV   $salt
-  - Generate HKDF hash value with 1 and 2. hash_hkdf('sha256', $ikm, $salt)+  - Generate HKDF hash value with 1 and 2. <nowiki> hash_hkdf('sha256', $ikm, 0, '', $salt) </nowiki>
   - Encrypt the user data with the key from 3   - Encrypt the user data with the key from 3
  
Line 111: Line 111:
   - Get system shared secret encryption key from secure place. $ikm   - Get system shared secret encryption key from secure place. $ikm
   - Get user ID which is unique in the system. $info   - Get user ID which is unique in the system. $info
-  - Generate HKDF hash value 1 and 2. <nowiki>hash_hkdf('sha256', $ikm, '', $info)</nowiki>+  - Generate HKDF hash value 1 and 2. <nowiki>hash_hkdf('sha256', $ikm, 0, $info)</nowiki>
  
  
-Note that both method uses "secret" information for $ikm. However, there is notable difference between these 2. This method uses only 1 secret key (encryption key) and info (user ID) is known to public, 1 stolen key allows attackers to decrypt all encrypted data while previous method requires 2 secret information to attack. (In addition, attackers have to steal all users password hash)+Note that both method uses "secret" information for $ikm. However, there is notable difference between these 2. This method uses only 1 secret key (encryption key) and info (user ID) is known to public, 1 stolen key allows attackers to decrypt all encrypted data while previous method requires 2 secret information(password hash and secret salt) to attack. (In addition, attackers have to steal all users password hash)
  
 There are many usages other than these two. Users can choose appropriate method for their needs. There are many usages other than these two. Users can choose appropriate method for their needs.
Line 124: Line 124:
  
 Setting up CSRF token Setting up CSRF token
-  - Get expiration timestamp as salt +  - Get expiration timestamp. ($salt) 
-  - Generate HKDF value with 1 and session ID +  - Generate HKDF value with 1 and session ID ($ikm).  <nowiki>hash_hkdf('sha256', $ikm, 0, '', $salt)</nowiki> 
-  - Send key from 2 and timestamp from 1 to browser as CSRF token+  - Send key from 2 and timestamp from 1 to browser as CSRF token.
  
 Verifying CSRF token Verifying CSRF token
-  - Get HKDF key and timestamp(salt) value from request +  - Get HKDF key and timestamp($salt) value from request. 
-  - Check if timestamp is not expired +  - Check if timestamp is not expired. 
-  - Generate HKDF value session ID and timestamp(salt) +  - Generate HKDF value from session ID($ikm) and timestamp($salt). <nowiki> hash_hkdf('sha256', $ikm, 0, '', $salt)</nowiki> 
-  - Compare HKDF value sent by browser and server generated HKDF value if it matches+  - Compare HKDF value sent by browser and server generated HKDF value if it matches.
  
 Secure CSRF token expiration can be defined with this method regardless of session ID lifetime. i.e. You can set short CSRF token expiration securely. Secure CSRF token expiration can be defined with this method regardless of session ID lifetime. i.e. You can set short CSRF token expiration securely.
Line 142: Line 142:
 https://www.owasp.org/index.php/Session_Management_Cheat_Sheet#Session_Expiration https://www.owasp.org/index.php/Session_Management_Cheat_Sheet#Session_Expiration
  
-Therefore, use of session ID as CSRF token key source is not recommended. You are better to use separate key for CSRF token generation in $_SESSION. e.g. $_SESSION['CSRF_TOKEN_IKM'] = session_create_id(); Use secret $_SESSION['CSRF_TOKEN_IKM'] for HKDF key generation where above example use session ID. With this method, you can generate secure HKDF CSRF token even when session ID is regenerated with your defined token expiration time. +Therefore, use of session ID as CSRF token key source is not recommended. You are better to use separate key for CSRF token generation in $_SESSION. e.g. $_SESSION['CSRF_TOKEN_IKM'] = session_create_id(); Use secret $_SESSION['CSRF_TOKEN_IKM'] for HKDF key generation where above example uses session ID. With this method, you can generate secure HKDF CSRF token even when session ID is regenerated with your defined token expiration time. 
  
 ==Use of info parameter== ==Use of info parameter==
Line 150: Line 150:
 ===== Proposal ===== ===== Proposal =====
  
-Internet RFC clearly recommends "salt" value whenever it is possible+Internet RFC clearly recommends "salt" value whenever it is possible. **Users are likely to omit optional parameters without consideration, especially the last one when there are less likely used parameters.**
  
-Change hash_hkdf() from+Change hash_hkdf() signature from
  
 <code> <code>
Line 167: Line 167:
  
 From user perspective, "salt" and "info" parameters can be used interchangeably. However, it would be good idea to follow RFC 5869 semantics.  From user perspective, "salt" and "info" parameters can be used interchangeably. However, it would be good idea to follow RFC 5869 semantics. 
-Unlike "info" which could be an optional, "salt" cannot be an optional with expiration enabled keys. This kind of expiration is common. e.g. Amazon AWS S3 uses HKDF with expiration to allow access to objects. +Unlike "info" which could be an optional in many cases, "salt" cannot be an optional with expiration enabled keys for instance. This kind of expiration is common. e.g. Amazon AWS S3 uses HKDF with expiration to allow access to objects. 
  
-Typical PHP applications that need HKDF can use (or should use) salt for security reasons as examples above. Users should consider if salt can be used or not. If use of salt is impossible, then it should set to be empty. They shouldn't omit salt without consideration which could lead serious security issue. Therefore, salt is better to be required parameter because typical PHP applications can supply salt.+Typical PHP applications that need HKDF can use (or should use) salt for security reasons as examples above. Users should consider if salt can be used or not. If use of salt is impossible, then it should set to be empty. Users shouldn't omit salt blindly. It could lead serious security issue. Therefore, salt is better to be required parameter because typical PHP applications can supply salt.
  
 ===== Discussions ===== ===== Discussions =====
rfc/improve_hash_hkdf_pramater.txt · Last modified: 2017/09/22 13:28 by 127.0.0.1

Page Tools