Frontline Information Protection

Size: px

Start display at page:

Download "Frontline Information Protection"

Clare Wood
5 years ago
Views:

Frontline Information Protection a presentation to the Phoenix Chapter of

attacks spring from weakly-coded web pages or compromised authentication

Many organizations have sprung up to provide guidance on programming

1 Frontline Information Protection a presentation to the Phoenix Chapter of ISACA by Hoyt L Kesterson II October 2014 OBSERVATION Most successful attacks spring from weakly-coded web pages or compromised authentication credentials. Many organizations have sprung up to provide guidance on programming around web vulnerabilities SANS Top 20 Open Web Application Security Project (OWASP) Many professionals will gather to give you password advice.

2 THESIS We make users create passwords that are difficult for them to remember but easy for computers to break *. * XKCD The Argument

3 The compliance chicken or egg PCI DSS Requirements Passwords/phrases must meet the following: Require a minimum length of at least seven characters. Contain both numeric and alphabetic characters Change user passwords/passphrases at least every 90 days Do not allow an individual to submit a new password/phrase that is the same as any of the last four passwords/phrases he or she has used. Six is not good but seven is? Increases the number of possible values. Complexity rules lead to ugly passwords. It irritates users. Makes it hard to remember passwords. If not compromised, what s the risk if you reuse? Cracking a password in real life In February 2011 Anonymous carried out a SQL injection attack against HBGary Federal. They acquired three MD5 hashes and sent them to the gang at Hashkiller.com. Back came 4036d5fe575fb46f48ffcd5d7aeeb5af:kibafo33 kibafo33 was the password for /facebook/twitter/ and whoknow-how-many-other accounts of Aaron Barr, CEO of HB Geary Federal. Anonymous was off to the races.

Determining a password The attacker either works with the password as entered by the

For the former, one can either social engineer for some good guesses, sniff it, or

4 So what is this hashkiller.com? One of many sites that offers tables of hashes of passwords plus discussion forums Determining a password The attacker either works with the password as entered by the user or as stored by the authenticator. For the former, one can either social engineer for some good guesses, sniff it, or brute force by submitting passwords from a dictionary, a big list of possible passwords. The latter can be done in parallel. Should be slowed or blocked by system reaction to successive failed attempts.

5 Passwords stored at authenticator should be cryptographically protected. InformationWeek on LinkedIn

6 InformationWeek on LinkedIn Hashes are not broken They are not being reversed let s do a hypothetical Not difficult to build table of all possible hash values

Put more possibilities in the set PCI DSS 8.5.10 & 11 say at least seven alphabetic and numeric.

7 Put more possibilities in the set PCI DSS & 11 say at least seven alphabetic and numeric. Microsoft says at least eight also including special characters. Failure codified into compliance standards. Available in 2003 People!

8 Backward compatibility is killing security If Lan Manager is enabled Password converted to all uppercase; Password padded to 14 characters; Split into two 7-character parts, i.e. 56 bits; Each part padded with a byte of zeros; Each part used as a DES key to encrypt KGS!@#$% to produce two hash values. If you cannot turn off LM hashing, choose a password whose length is over 14 characters.

You would need a large table to hold all the possible hashes for a large set of passwords. Rainbow tables provide a way to efficiently store the passwords and associated hashes.

ophcrack was first; RainbowCrack latest Salting hashes makes tables of hashed passwords useless. At the end of the 1 st line of defense salt Add a salt into the hashing process.

9 You would need a large table to hold all the possible hashes for a large set of passwords. Rainbow tables provide a way to efficiently store the passwords and associated hashes. More time to search but less memory Tuples are associated in chains using reductions, i.e. a transformation of the hash into plaintext. ophcrack was first; RainbowCrack latest Salting hashes makes tables of hashed passwords useless. At the end of the 1 st line of defense salt Add a salt into the hashing process. Different salt value gives different hash values for the same password. hashcat can use GPU, e.g. AMD Radeon HD 7970, to produce hashes very quickly. 4.7 billion MD5 hashes per second 2.2 billion SHA-1 hashes per second Not fast enough for salting exhaustive dictionary unless constant salt used by target. Fast enough for salting selective dictionary.

hashcat on roids At the Passwords^12 conference in December 2012, Jeremi Gosney demonstrated his implementation of hashcat running on multiple GPUs 25 AMD Radeon GPUs VirtualOpenCL

second Six minutes to generate all possibilities 2 nd line of defense difficulty SHA-256 is not the answer You want an algorithm that is fast enough to avoid a perceptible delay to

10 hashcat on roids At the Passwords^12 conference in December 2012, Jeremi Gosney demonstrated his implementation of hashcat running on multiple GPUs 25 AMD Radeon GPUs VirtualOpenCL (VCL) was extended to support 128 GPUs Generates 348 billion NTLM hashes per second 180 billion MD5 hashes per second 63 billion SHA1 hashes per second 20 billion LM hashes per second Six minutes to generate all possibilities 2 nd line of defense difficulty SHA-256 is not the answer You want an algorithm that is fast enough to avoid a perceptible delay to the user, but Makes the computing of a large number of hashes untenable. Fortunately, you don t need to write this yourself. bcrypt, PBKDF2 multiple iterations adaptable to future hardware

11 thisisavery (11 chars) thisisaveryverylongpassword (27 chars) No complexity no upper case, numerals, or special characters

12 Create Strong Passwords

13 Changed on a periodic basis to counter the possibility of undetected password compromise. changed often enough acceptably low probability of compromise during a password s lifetime. There s a flaw in the reasoning Is it likely that the compromise happened just before you changed the password? Is it just as likely that the compromise happened immediately after you changed the password? Are we to be satisfied with the mean? forty-five days if following PCI DSS ninety or more if following the DOD guidance. Perhaps longer passwords kept for a longer time is a better defense.

14 The effectiveness of a prophylactic password change For a continuous series of logon attempts are you hoping the new password is one that has already been submitted? If the hash table attack software has the hash of your current password, it s very likely that it also has the hash of the replacement password (and the password you ll use a year from now). Get yourself out of the table Only change passwords when there is a known or suspected compromise; or, you want a stronger password. Upon successful login notify user of: date and time of user s last login, location of user at last login; and, unsuccessful login attempts since last login.

15 We shouldn t be doing these at all Requiring unmemorable passwords. six-characters with at least one upper-case, one-lower case, one numeral, and one special character. Requiring a password change unless suspected or known to be compromised. Inadequately protecting stored passwords. There s little excuse for not using a function that s been around since The compliance chicken or egg PCI DSS Requirements Passwords/phrases must meet the following: Require a minimum length of at least seven characters. Contain both numeric and alphabetic characters Change user passwords/passphrases at least every 90 days Do not allow an individual to submit a new password/phrase that is the same as any of the last four passwords/phrases he or she has used. Auditor will accept very long passwords. It will be difficult to convince auditor that length is enough. What is this preventing? But difficult to convince auditor. What is this preventing? But difficult to convince auditor.

16 The compliance chicken or egg PCI DSS Requirements Passwords/phrases must meet the following: Require a minimum length of at least seven characters. Contain both numeric and alphabetic characters Change user passwords/passphrases at least every 90 days Do not allow an individual to submit a new password/phrase that is the same as any of the last four passwords/phrases he or she has used states Much stronger password not likely to be compromised May not be an issue if user isn t forced to change password as frequently. Doing something different You don t have to do what the DSS requirement states. You can use another method, a compensating control, if that control meets the intent and rigor of the control documented in the DSS; mitigates risks at least as effectively as the original control; does not require an existing control already mandated by the DS; e.g. if a server could not support malware monitoring as stated in requirement 5, file integrity monitoring could not be the compensating control since that control would be already required for the server; mitigates any risk caused by not adhering to the original control, and remains effective after the assessment is complete. Each compensating control must be documented in a Compensating Controls Worksheet, which is described in Annex C of the DSS.

17 The Compensating Controls Worksheet Who goes first The PCI standards group do not create standards; they use existing standards. No one is working on improving password standards The new text on equivalent strength of passphrases can be used by a company as a justification for going to longer passphrases without a complexity requirement and is changed only once a year. But putting the new policies in place, documenting them, and training users can be a large investment. Any hint that the auditor will not accept alternative methods of proven greater strength will dampen enthusiasm. Auditors, what can you do to help?

18 ?

Passwords and Equivalent Strength the loophole in the DSS

Passwords and Equivalent Strength the loophole in the DSS NORTH AMERICA COMMUNITY MEETING VANCOUVER 29 SEPTEMBER 1 OCTOBER 2015 Hoyt L Kesterson II Senior Security Architect Terra Verde The Wisdom of Dexter