Enterprise Security API (ESAPI) 2.0 Crypto Changes. Kevin W. Wall ESAPI Project co-owner [email protected]. September 21, 2011. Obligatory CV. 20+ years developer experience, 12 yrs security experience 17 yrs at (now Alcatel-Lucent) Bell Labs; left as DMTS - PowerPoint PPT Presentation
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
– Default algorithm was PBEWithMD5AndDES• PBE → Keys vulnerable to dictionary attacks
• Weak algorithms (DES and MD5)
• Uses CBC cipher mode and PKCS5 padding
– Restricted to single encryption key
– Default setting for MasterSecret & MasterSalt
– No message authenticity for ciphertext
Why the ESAPI 2.0 Crypto Changes?
• ESAPI 2.0rc1 / 2.0rc2 implementations
– Default algorithm was 256-bit AES• Better, but...
• Uses ECB mode and no way to use another mode
– Still restricted to single encryption key
– Still default setting for MasterSecret & MasterSalt
– Still no message authenticity
What's Wrong with ECB Mode?
Original Tux Image Tux Encrypted w/ ECB Mode
Encrypted w/ other than ECB
Why Do We Need Message Authenticity?
• Ensures IV + ciphertext is authentic (not tampered with)
– So what?• Umm... Padding Oracle Attack
Aside: Padding Oracle Attack
• What is it?
– First described in 2002 in context of IPSec by Serge Vaudenay
– Attack on CBC mode of operation where “oracle” leaks info whether or not padding of ciphertext is correct.• Oracle typically is either different error messages being returned or
timing side-channel attack.
• So what's the harm?
– Allows adversary to decrypt (and encrypt) data without knowledge of the secret key.
– Is efficient: Works without a large “work factor”• Reference: Brian Holyfield’s NYC OWASP presentation:
• It's an invitation to join Google+ that you email to your friends. Presumably, this is a cryptographic token (although it could just be an object reference into some database).
Question: What if you wanted to implement something similar, but say for a coupon service that you could email to one of your friends for some specific merchandise and you didn't want to have to store it in a database?
• You could do it with an appropriate cryptographic token.
Advanced Crypto Example (cont'd)What information would you need in this cryptographic token? How
about:1) The currently authenticated user's user account name
2) The target user account name of your friend
3) A merchandise ID
4) The coupon value
5) The coupon expiration date
Of course, you want it to be secure in the following sense:a) protection of all identities involved (confidentiality)
b) unforgeable
c) secure from tampering
d) immune to replay attacks
How much code would that take you?
Advanced Crypto Example (cont'd)
With ESAPI, it's something like this:// Creating the token…CryptoToken ctok = new CryptoToken();ctok.setUserAccountName( ESAPI.authenticator().getCurrentUser() );ctok.setAttribute("targetUserAcct", targetUserName);ctok.setAttribute("merchandiseID", merchandiseId);ctok.setAttribute("couponPrice", price);byte[] nonce = ESAPI.randomizer().randomBytes(16);ctok.setAttribute("nonce", Hex.toHex(nonce, false) );// Store nonce somewhere to prevent replays.ctok.setExpiration( 30 * 24 * 60 *60 ); // 30 days (in secs)return ctok.getToken(); // Return encrypted token
Advanced Crypto Example (cont'd)
// Consuming the token…CryptoToken ctok = new CryptoToken(tokenString);
Date expDate = ctok.getExpirationDate();
// Check if expDate > current date and do something ...
String hexNonce = ctok.getAttribute("nonce");
// Check if nonce replayed; error if yes. Rm from table...