13
Copyright © The OWASP Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the OWASP License. The OWASP Foundation ESAPI Summit – OWASP AppSec USA 2011 http://www.owasp.org/ Enterprise Security API (ESAPI) 2.0 Crypto Changes Kevin W. Wall ESAPI Project co-owner [email protected] September 21, 2011

Enterprise Security API (ESAPI) 2.0 Crypto Changes

  • Upload
    ojal

  • View
    50

  • Download
    0

Embed Size (px)

DESCRIPTION

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

Citation preview

Page 1: Enterprise Security API (ESAPI) 2.0 Crypto Changes

Copyright © The OWASP FoundationPermission is granted to copy, distribute and/or modify this document under the terms of the OWASP License.

The OWASP Foundation

ESAPI Summit – OWASP AppSec USA 2011

http://www.owasp.org/

Enterprise Security API(ESAPI) 2.0 Crypto Changes

Kevin W. WallESAPI Project [email protected]

September 21, 2011

Page 2: Enterprise Security API (ESAPI) 2.0 Crypto Changes

Obligatory CV• 20+ years developer experience, 12 yrs security

experience

• 17 yrs at (now Alcatel-Lucent) Bell Labs; left as DMTS

• 3.5 yrs as independent contractor (C++ & Java)

• 12 years application & information security experience

• Currently: Staff Security Engineer at CenturyLink (formerly Qwest)

• OWASP ESAPI for Java• Project co-owner

• Cryptography developer (since 2.0rc2)

• OWASP ESAPI for C++

• Meddlesome troublemaker

• Blog: http://off-the-wall-security.blogspot.com/

Page 3: Enterprise Security API (ESAPI) 2.0 Crypto Changes

Why the ESAPI 2.0 Crypto Changes?

• ESAPI 1.4 implementation

– 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

Page 4: Enterprise Security API (ESAPI) 2.0 Crypto Changes

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

Page 5: Enterprise Security API (ESAPI) 2.0 Crypto Changes

What's Wrong with ECB Mode?

Original Tux Image Tux Encrypted w/ ECB Mode

Encrypted w/ other than ECB

Page 6: Enterprise Security API (ESAPI) 2.0 Crypto Changes

Why Do We Need Message Authenticity?

• Ensures IV + ciphertext is authentic (not tampered with)

– So what?• Umm... Padding Oracle Attack

Page 7: Enterprise Security API (ESAPI) 2.0 Crypto Changes

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:

http://blog.gdssecurity.com/storage/presentations/Padding_Oracle_OWASP_NYC.pdf

Page 8: Enterprise Security API (ESAPI) 2.0 Crypto Changes

Major Changes in ESAPI 2.0 Crypto

• Deprecated, then removed, unsafe methods

• Added support for CipherText objects

• Added support for PlainText objects

• Added support for multiple secret keys

• Added support for message authenticity

• Added support for multiple cipher modes (but using multiple ones w/in app still a kludge [potential race condition])

• Changed to use strong default accessible to all Allows AES/CBC/PKCS5Padding with 128-bit key and random IV

Authenticity generally provided by HMAC-SHA1

Page 9: Enterprise Security API (ESAPI) 2.0 Crypto Changes

Advanced Crypto Example

• So, for any of you using Google+, does this look familiar?

https://plus.google.com/_/notifications/ngemlink?path=%2F%3Fgpinv%3DgU47oPXLOt8%3Apox7sn5mwqF

• 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.

Page 10: Enterprise Security API (ESAPI) 2.0 Crypto Changes

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?

Page 11: Enterprise Security API (ESAPI) 2.0 Crypto Changes

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

Page 12: Enterprise Security API (ESAPI) 2.0 Crypto Changes

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...

String targetUserName = ctok.getAttribute("targetUserAcct");

String MerchandiseId = ctok.getAttribute("merchandiseID");

String price = ctok.getAttribute("couponPrice");

// Logic to remove available coupons from originating user

String userAcctName = ctok.getUserAccountName();

...

Page 13: Enterprise Security API (ESAPI) 2.0 Crypto Changes

Q&A

Ask now, or email me at: <[email protected]>