tag:blogger.com,1999:blog-29202771179283896472024-03-05T07:21:54.044-06:00PasswordResearch.com Authentication NewsInteresting authentication tidbits from the PasswordResearch.com founder, Bruce K. Marshall.Bruce K. Marshallhttp://www.blogger.com/profile/07397177700712500000noreply@blogger.comBlogger20125tag:blogger.com,1999:blog-2920277117928389647.post-61238625502962743952019-05-09T11:28:00.000-05:002019-05-09T11:34:34.535-05:00Thoughts on new authentication guidance in OWASP Application Security Verification Standard (ASVS) v4.0<br />
[This content was originally posted in a <a href="https://twitter.com/PwdRsch/status/1124076820196941824" target="_blank">series of tweets</a>, but it also made sense to share it here.]<br />
<br />
OWASP released <a href="https://github.com/OWASP/ASVS" target="_blank">v4.0 of the Application Security Verification Standard (ASVS)</a> in March, listing security practices for organizations to design, code,
and test apps against. There were substantial content changes in the authentication section, so after reviewing it I wanted to tell you what I thought about the changes.<br />
<br />
The authors state in the V2 Authentication Verification Requirements section
that their goal is bringing this standard closer in line with
significant authentication changes published by NIST in the <a href="https://pages.nist.gov/800-63-3/" target="_blank">SP 800-63 Digital Identity Guidelines</a> update that came out after ASVS v3.0.<br />
<br />
There are 57 requirements in section 2 for ASVS version 4.0, compared to 26
in the same section of 3.0, which more than doubles the number of previous requirements. Around 9 requirements are seemingly removed in
4.0. So let's go through some of the notable changes to the standard.<br />
<br />
Requirement 2.1.1 establishes a minimum password length of 12 characters
for users, which is one big divergence from NIST’s minimum of 8 chars.
While this is justifiable for security, I do think it will cause
protests, especially if dealing with third-party or legacy apps that have hard-coded lower length settings.<br />
<br />
2.1.4 asks for support of Unicode characters in passwords. Another good
change, and while I don’t have statistics I suspect a large number of
Internet apps can’t meet this requirement today. Many of them are still
struggling just to allow symbols (see <a class="twitter-atreply pretty-link js-nav" data-mentioned-user-id="740008316076593157" dir="ltr" href="https://twitter.com/PWTooStrong" target="_blank">@PWTooStrong</a>).<br />
<br />
2.1.6 talks about verifying the old password to select a new password,
but removes text from older standard about new password confirmation. I
suspect that with the addition of 2.1.12 saying to add a password field
unmasking option that OWASP made this change for usability (see <a href="http://uxmovement.com/forms/why-the-confirm-password-field-must-die/" target="_blank">Why the Confirm Password Field Must Die</a>).<br />
<br />
Requirement 2.1.7 expands on previous guidance to prevent use of
common/weak passwords to specifically recommend use of a 1,000 - 10,000
entry blacklist, either maintained locally or transmitted securely using
a third party like <a class="twitter-atreply pretty-link js-nav" data-mentioned-user-id="2191981764" dir="ltr" href="https://twitter.com/haveibeenpwned" target="_blank">@haveibeenpwned</a> or <a href="https://techcommunity.microsoft.com/t5/Azure-Active-Directory-Identity/Azure-AD-Password-Protection-is-now-generally-available/ba-p/377487" target="_blank">Azure AD Password Protection</a>.<br />
<br />
2.1.9 says to eliminate any password complexity policy requirements or
restrictions. This places responsibility on blacklists and minimum
password lengths to prevent bad password choices. It's a very
contentious change for orgs who've used complexity policies for decades.<br />
<br />
Speaking more generally, the migration away from password complexity
policies to blacklists is a major shift that needs additional research.
If you implement password blacklisting within your org please find a way to share your
lessons learned, anonymously if needed, so we can all benefit.<br />
<br />
New requirement 2.1.8 says to provide a password strength meter to guide users towards choosing stronger passwords or passphrases. However, not all meters are created equally, so I recommend taking the time to select a good one (see <a href="http://www.passwordresearch.com/papers/paper799.html" target="_blank">On the Accuracy of Password Strength Meters</a>)<br />
<br />
2.1.10 instructs the removal of password expiration policies, which has
gained support in recent years. But this goes hand-in-hand with
requirement 2.2.1 to implement controls to combat password attacks and
reduce the chances of a password compromise leading to account takeover.<br />
<br />
Requirement 2.2.2 discourages relying on ‘weak authenticators’ like SMS
and email. 2.2.4 and 2.2.7 advocate prioritizing reliance on MFA
options less likely to be compromised, like OTP tokencodes, U2F security
keys, or client-side certificates.<br />
<br />
2.2.3 says to securely notify users following any changes to their
credentials, emails, addresses, or if new logins to their accounts occur
from a riskier/previously unknown location. The use of push
notifications is preferred to better direct user attention to these
events.<br />
<br />
Requirements in 2.4 expand OWASP guidance on password storage to include
aspects like salt randomness and length. But they don’t mention Argon2
or scrypt, instead offering work factor advice for bcrypt and an oddly
inflated PBKDF2 iteration count of 100,000 (NIST is satisfied with 10,000).<br />
<br />
They do discuss Argon2 and scrypt in the OWASP <a href="https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Password_Storage_Cheat_Sheet.md" target="_blank">Password Storage Cheat Sheet</a>, so it’s likely these documents just need to be aligned better. The PBKDF2 iteration count discrepancy may just be a typo.<br />
<br />
2.5.2 now calls for the elimination of security questions rather than
just <a href="http://passwordresearch.com/papers/paper180.html" target="_blank">making sure the ones in use are ‘good’</a>. Many industries, especially
US banking, still rely on these for secondary authentication. But with
stronger MFA options OWASP thinks they can be phased out.<br />
<br />
Sections 2.6 and 2.7 are brand new and describe recommended security
elements for Transaction Authorization Numbers (TANs) and out-of-band
(OOB) authenticators. These tie back directly to NIST guidance for
designing or implementing these solutions.<br />
<br />
Section 2.8 likewise gives guidance on one-time password (OTP)
authenticator use, with section 2.9 discussing cryptographic security
key authenticators (FIDO U2F). You may not develop these functions
in-house but should validate that your vendor has done so properly.<br />
<br />
Section 2.10 adds further guidance on storage of passwords or API keys
used by application code, including not to “rely on unchanging
passwords”. I think a better word would be “unchangeable” so they
should be updated as needed but not on a set schedule.<br />
<br />
So what was removed in section 2 of the new 4.0 ASVS? Some practices in the old
standard may have been considered too basic, such as ‘require
authentication for anything non-public’, ‘enforce authentication on the
server’, and ‘fail securely to a default deny.’<br />
<br />
The old 2.2 is removed which stated “Verify that forms containing
credentials are not filled in by the application.” This could be
understood to include password managers autofilling credentials, rather
than just browsers, which OWASP may have decided to no longer
discourage.<br />
<br />
One absence is the old 2.23 practice of making sure account lockout due
to login failures was flagged separately from administrative account
disabling. It was a logical recommendation, so I don’t know if it was
also considered too basic or whether it's removal is an oversight.<br />
<br />
Also removed is the 2.28 guidance to ‘make sure all authentication
challenge responses take the same time.’ Intended to prevent things
like timing attacks that leak credential info, this may have been
thought to be too difficult to implement consistently for the value it
provided.<br />
<br />
Old practice 2.32 wanted you to make sure administrative interfaces
weren’t accessible to untrusted networks. This may have been removed
because it becomes more difficult in a cloud-hosted world, or maybe
because some apps use the same login interface for admins and normal
users. [project lead Andrew van der Stock <a href="https://twitter.com/vanderaj/status/1124868333050798080" target="_blank">commented</a> "We did that because "where" is not as important as "who". The idea of Fortress Admin is laughable and always has been. Let's move beyond layer 3 restrictions."]<br />
<br />
Finally, gone is the old 2.18 requirement to verify that username
enumeration isn’t possible in login or account recovery functions. While
preventing account enumeration is good, it tends to provide <a href="https://security.stackexchange.com/questions/62661/generic-error-message-for-wrong-password-or-username-is-this-really-helpful/62667#62667" target="_blank">little value at the expense of the user experience</a>.<br />
<br />
I created a Google spreadsheet to compare the section 2 authentication
requirements of the ASVS 4.0 and 3.0 side by side. You can access it
here: <a href="https://docs.google.com/spreadsheets/d/1UbOsbgv4WsmuVuL8M3NoCRD7UQKAw7vl6BLYaLk-EtI/" target="_blank">https://docs.google.com/spreadsheets/d/1UbOsbgv4WsmuVuL8M3NoCRD7UQKAw7vl6BLYaLk-EtI/</a><br />
<br />
Wrapping up this review, I want to thank the OWASP organizers and volunteers who developed this
standard and made the tough decisions about what practices to
include/exclude. Project leads include <a class="twitter-atreply pretty-link js-nav" data-mentioned-user-id="25798476" dir="ltr" href="https://twitter.com/vanderaj" target="_blank">@vanderaj</a> <a class="twitter-atreply pretty-link js-nav" data-mentioned-user-id="2863808158" dir="ltr" href="https://twitter.com/JoshCGrossman" target="_blank">@JoshCGrossman</a> <a class="twitter-atreply pretty-link js-nav" data-mentioned-user-id="14461330" dir="ltr" href="https://twitter.com/dcuthbert" target="_blank">@dcuthbert</a> <a class="twitter-atreply pretty-link js-nav" data-mentioned-user-id="785486180" dir="ltr" href="https://twitter.com/m8urnett" target="_blank">@m8urnett</a> & <a class="twitter-atreply pretty-link js-nav" data-mentioned-user-id="55695175" dir="ltr" href="https://twitter.com/manicode" target="_blank">@manicode</a>.<br />
<br />Bruce K. Marshallhttp://www.blogger.com/profile/07397177700712500000noreply@blogger.com0tag:blogger.com,1999:blog-2920277117928389647.post-55884243650348185602015-05-08T01:00:00.002-05:002022-03-02T10:16:50.873-06:00When Should You Change Your Password?May 7th is known as Password Day on the Internet. The annual event is used to draw attention to common password problems and offer tips to people for choosing and managing passwords better. Found among this advice is guidance to change your passwords on this day, or to at least change them regularly. Unfortunately, this practice it isn't as clearly beneficial as those offering it might hope.<br />
<br />
The reality is that we security professionals have been advocating regular password changes, and sometimes forcing users to comply, for decades with very little evidence that it is useful. The only reason to change a password is if we know an attacker has obtained it or if we suspect this is likely. We simply don’t have data that shows regular password changes do make an impact on the problem of password theft.<br />
<br />
I gave a presentation on <a href="http://www.passwordresearch.com/Expire.html" target="_blank">password expiration for a technical audience</a> at PasswordsCon last year, but it didn't address the challenge from a user's point of view. So, I wrote this related article for the average Internet user, and not only technology or security industry veterans.<br />
<br />
With that background, here are the questions I would ask yourself before changing your passwords. I've listed these from the most important questions to the least important.<br />
<br />
<h4>
Has a company told you that they've had a security breach and recommended you change your password?</h4>
Usually responsible companies will alert users if they have suffered a security intrusion that put user passwords at risk. This alert will hopefully come in the form of an email or letter to you, but might also show up as an notification when you log into their site. Some sites force you to change your password following a breach, while others simply recommend you change it and leave that decision up to you.<br />
<br />
On some sites your stolen password may be cryptographically protected, but this may only buy you a few days or weeks following a breach before attackers can 'crack' them and start using your account. I recommend quickly changing your password in any situation where you've been alerted there was a security breach.<br />
<br />
If you have used this same compromised password on other sites you should also change those passwords to a new value since some attackers will try to use your credentials everywhere they can.<br />
<br />
<h4>
Have you noticed suspicious account activity on a site?</h4>
Sometimes noticing suspicious activity with your account on a site is easy. If you see posts on your Facebook account that you didn't make, that’s a pretty good sign something is wrong. Likewise, unfamiliar purchases or other financial transactions on an account is a red flag.<br />
<br />
But other times there may be more subtle clues that you’ll have to search for. Are messages marked as read when you haven’t reviewed them? Was the last account login time recorded when you weren't using your account? Has your email address, phone number, or home address been updated to an unfamiliar value?<br />
<br />
Some sites are very good about helping you notice unusual behavior, such as when someone logs into your account from a new computer or device. These companies might send you an email to alert you of this behavior or of sensitive changes to your account. While scammers sometimes fake these emails in ‘phishing’ attacks, you can often avoid clicking links in suspicious emails and log directly into the site to see if the warning is legitimate.<br />
<br />
If you see reasonable signs that someone else has been using your account then this is also a good time to change your password.<br />
<br />
<h4>
Have you logged in from a shared computer or had a virus since your last password change?</h4>
Shared computers are the type you might find in a library, school, Internet/gaming cafe, or hotel. They aren't owned by you and they typically don’t offer much reassurance that they are secure against malicious tampering. An attacker can install software to capture any passwords you type while on the computer, and then use that information to later impersonate you.<br />
<br />
If you want to log into a site while on a shared computers then consider changing any passwords you used once you are back on a trusted computer or mobile device. Otherwise you might want to avoid shared computer use altogether since there’s a chance an attacker can carry out their crimes before you have time to change passwords.<br />
<br />
If your computer or mobile device has been infected with a virus or other malware there’s also a good chance your passwords were captured during the infection. Once you are certain that the malicious software has been removed you should consider changing any passwords that were exposed. If you still have malicious software on your computer then simply changing your password may not help. The criminals will be able to capture your new password when you type it in and they can continue to misuse it.<br />
<br />
If you aren't sure how long your computer was infected, and thereby what passwords are at risk, it might make sense to change the passwords of your most valuable accounts first and monitor your less valuable accounts for any sign of suspicious activity, changing more passwords as necessary.<br />
<br />
<h4>
Have you shared a password with someone who you no longer trust or who you may have trusted too much?</h4>
While you generally shouldn't make a practice of sharing your passwords, there are times where you probably will. Maybe a significant other needs to read important messages for you while you’re out, or you share an account for a service that the whole family uses.<br />
<br />
Problems with this habit tend to arise when either a breakup or other relationship distress occurs that changes how much you can continue trusting the person with your password. Amidst the usual stress of these events it is still important to take the time to think about what accounts are now exposed to potential abuse and to make password changes where needed. Even if you part on good terms, it can still be a good idea to remove the possibility of someone’s curiosity or jealousy later tempting them to get into your accounts.<br />
<br />
Other situations you should be careful with are people who ask for your password with seemingly legitimate motives that you later begin to distrust. For example, maybe you get a phone call from someone representing a company that claims to be fixing a problem for you but needs your password. Or maybe a coworker or fellow student is working on a project with you and needs your password to access shared information.<br />
<br />
In these situations you might comply with the request initially and realize after the fact that it probably wasn't a good idea. Change these passwords and think about how to avoid these situations in the future.<br />
<br />
<h4>
Have you used this same password on another site that is much less valuable?</h4>
Another common password recommendation is that you use a unique password for every site you log into. This recommendation it is very helpful in limiting abuse of your accounts if you choose to follow it. However, many people share passwords between at least some of their accounts to ease the burden of memorizing a long list of secrets.<br />
<br />
If you've chosen to share some passwords then I recommended using unique passwords for your most important accounts (banking, medical, email), and only sharing passwords for less important sites. For example, you may choose to have the same password for Facebook and Twitter if it doesn't bother you than an attacker may be able to get into both accounts without additional effort on their part. You might also share a single password between all news or entertainment sites you visit if you don’t have any financial info tied to them.<br />
<br />
What you should avoid is using the same password for an important site (e.g. your bank) and a less important site that may not do a good job protecting your account. Sites that don’t deal with sensitive info typically have less comprehensive security, which can leave them more susceptible to hacking. If an attacker steals your password from one of these sites you want to prevent them from getting into your other accounts that do contain sensitive data.<br />
<br />
So if you've shared a password between accounts like this you probably should change the password of the more important site to something unique.<br />
<br />
<h4>
Has it been a few years since you've last changed your password?</h4>
Finally, after reviewing all these other factors, you can consider how long it has been since you last changed a particular password. This acts as a catch-all in case you didn't notice suspicious activity, didn't remember sharing a password, didn't know you were infected with a virus, etc.<br />
<br />
The only problem with this approach is that we don’t know how often changing a password simply based on its age is actually useful. We have no idea whether changing a password every 6 months prevents enough hacking to justify that time frame compared to changing it every year. Our industry has adopted guidelines, mainly for corporate passwords, but these are founded in habit rather than careful scientific reason.<br />
<br />
So I won’t pretend that there is a lot of value in setting an arbitrary date on when a password should be changed. If it makes you feel better to change them every few years, and you don’t mind the work, then go ahead and do it. If you don’t want to change them regularly, and aren't required to, then I would focus that energy on running through the above questions on a regular basis. In the long run this latter practice will probably prove to be more valuable to you.<br />
<br />
<h4>
So you've decided to change a password</h4>
To make changing your password worthwhile your new one should be something unrelated to the previous password value. Going from “Muffins14” to “Muffins15” probably won’t protect you from an attacker committed to accessing to your account.<br />
<br />
I would also strongly recommend that you take this opportunity to start using a password manager if you aren't already. Password managers act as a backup to your memory so you feel more comfortable choosing better passwords and changing them as needed. Some password managers can even supply your password automatically to the sites you log into, removing the burden on your memory entirely. <br />
<br />
Here are a few of the more popular password managers:<br />
<br />
Free versions:<br />
- <a href="http://passwordsafe.sourceforge.net/" target="_blank">PasswordSafe</a><br />- <a href="http://keepass.info/" target="_blank">KeePass</a><br />
<br />
Paid versions:<br />
- <a href="https://agilebits.com/onepassword" target="_blank">1Password</a><br />
- <a href="https://www.dashlane.com/" target="_blank">Dashlane</a><br />- <a href="https://lastpass.com/" target="_blank">LastPass</a><br /><br />
<br />
While you are changing your passwords look in your account settings for two-factor authentication (2FA), or any multi-factor authentication (MFA) support on the site that you may not yet be using. MFA adds another layer of account protection, usually in the form of a one-time code texted to you, a pop-up alert on your phone, or other mechanism designed to supplement the security of passwords. These mechanisms add another hurdle for attackers to overcome before gaining access to your account, and have the side benefit of rendering regular password changes even less necessary.<br />
<br />
More and more sites are starting to support MFA to protect accounts, and I would encourage you to try it out and take advantage of the added security. <br />
<br />Bruce K. Marshallhttp://www.blogger.com/profile/07397177700712500000noreply@blogger.com0tag:blogger.com,1999:blog-2920277117928389647.post-4669758577901259692014-09-04T10:53:00.001-05:002014-09-04T10:53:13.822-05:00Are Recent Password Guessing Attacks Tied to Devastating Morris Worm?With recent reports of online password guessing attacks, like those <a href="http://www.apple.com/pr/library/2014/09/02Apple-Media-Advisory.html" target="_blank">Apple customers may have experienced</a>, is it possible that the Morris worm is responsible? Yes, I mean the <a href="http://en.wikipedia.org/wiki/Morris_worm" target="_blank">Morris worm from 1988</a>. The one that impersonated users with weak passwords as part of an attack arsenal that allowed it to spread and overwhelm the then nascent Internet. Since password guessing was detected shouldn't we assume this worm has resurfaced?<br />
<br />
“But Bruce,” you protest, “you're offering no evidence that these things are in any way associated!” And to you I reply “Well, why should that stop us from speculating?”<br />
<br />
Ok, my claim is a bit exaggerated but it was inspired by real news from <a href="http://community.namecheap.com/blog/2014/09/01/urgent-security-warning-may-affect-internet-users/" target="_blank">Namecheap on Monday</a>. The web hosting company warned customers that they had detected a credential guessing attack, which “likely” matched a recently revealed Russian password collection. This collection, publicized by security consultant Alex Holden in August, purportedly included 1.2 billion unique credentials stolen by a hacking group nicknamed "CyberVor". It attracted a lot of attention in the news, <a href="http://www.forbes.com/sites/thomasbrewster/2014/08/12/alex-holden-explains-data-breach-profiteering-defense/" target="_blank">along with its own controversy</a>.<br />
<br />
So why did Namecheap think the attempted usernames and passwords were associated with CyberVor? They don't offer a reason in their posted warning. Furthermore, I don't believe they have a good reason. The Russian credential cache has not been made public so there are no username or password records for them to compare to the guesses they saw.<br />
<br />
My suspicion is that the CyberVor story was still fresh in the mind of
someone at Namecheap and they made an assumption that the group's data was involved when faced with
their own attack. Maybe there was also some circumstantial evidence, such as password guesses originating from Russian IP addresses. Regardless,
there's no apparent way for them to know and there's likewise no reason to assume there is
a connection. <br />
<br />
I can forgive a company for including a seemingly unrelated statement when they aren't accustomed to disclosing details about an attack, but what really bothered me was how a few members of the media failed to question it.<br />
<br />
An article by <a href="http://www.theregister.co.uk/2014/09/02/cybervor_linked_hack_detected/" target="_blank">The Register</a> mentioned that the Namecheap news offered "anecdotal evidence" of a CyberVor connection but seems to otherwise present the information as fact. <a href="http://www.infosecurity-magazine.com/news/russian-gangs-billions-of-stolen/" target="_blank">Infosecurity Magazine's</a> coverage also didn't question how the two events were related, and goes on to wonder if it was the first time the Russian credentials were used in an attack against another site.<br />
<br />
I understand that news cycle driven journalism means not being
able to fact check every detail being shared, but I feel like the Namecheap claim was important enough to raise a red flag, especially at these two publications.<br />
<br />
Meanwhile, <a href="http://www.csoonline.com/article/2600773/security/namecheap-says-accounts-compromised-in-hacking-incident.html" target="_blank">IDG News Service</a> did challenge how Namecheap could make this connection and
actually took the time to ask Alex Holden (the only person outside of
CyberVor known to have a copy of their credential cache) about the claim.
Holden agreed that there wasn't support for thinking CyberVor data was involved. A <a href="http://www.securityweek.com/namecheap-says-accounts-accessed-credentials-stolen-russian-hackers" target="_blank">SecurityWeek</a> article also questioned whether timing of the two incidents was the only
evidence that led to the conclusion, and apparently did try to verify the statement with Namecheap.<br />
<br />
In reality, automated password guessing, or brute-forcing, attacks have been a threat long before CyberVor made the news. The US Department of Defense <a href="http://fas.org/irp/nsa/rainbow/std002.htm" target="_blank">Password Management Guidelines</a> advised setting minimum password policy standards to combat the threat of login password guessing back in 1985. Although since the cutting edge technology of that day required passwords to be tried over 1200 baud modems the attacks took a slight bit longer to carry out.<br />
<br />
More recently, both web sites and <a href="http://www.passwordresearch.com/papers/paper160.html" target="_blank">other Internet services</a> have faced increased password guessing attacks. In 2012 the video game development company ArenaNet (who hosts the Guild Wars 2 MMO) responded to <a href="http://arstechnica.com/security/2012/09/guild-wars-2-password-attack-affects-10000-accounts/" target="_blank">thousands of customer support tickets</a> when criminals successfully guessed player passwords. Last year, both <a href="http://www.konami.jp/osirase/130709/statement_en.pdf" target="_blank">Konami (PDF)</a> and <a href="http://kotaku.com/in-japan-nintendo-was-hacked-675798797" target="_blank">Nintendo</a> experienced millions of login attempts, taking place over several weeks, aimed at compromising their customer accounts.<br />
<br />
One factor these attacks all seemed to share was that the hackers behind them were leveraging usernames and passwords stolen from other hacked sites. The dangerous and common practice of <a href="http://www.passwordresearch.com/stats/statistic276.html" target="_blank">reusing passwords</a> for different companies can mean that your site is more vulnerable to attack if you have users that also maintain accounts on less secure sites. If one of those sites is breached and their user database is stolen (possibly with <a href="http://plaintextoffenders.com/" target="_blank">passwords stored in plaintext</a>) it can improve the success that criminals have when attempting to guess credentials on your site. This likelihood of success probably grows when the hacked site and yours both cater to a similar customer base.<br />
<br />
So while it is likely that the credentials tried against Namecheap customer accounts originated from one or more hacked sites, there are plenty of more likely sources for <a href="http://blog.passwordresearch.com/2013/02/passwords-found-in-wild-for-january-2013.html" target="_blank">collecting password records</a> other than the CyberVor stash.<br />
<br />
On a positive note, Namecheap does deserve praise for having monitoring in place to detect unusual login activity, which allowed them to quickly take steps to protect their customers' accounts. Instead of the weeks noted above in the Konami and Nintendo cases, Namecheap personnel responded within hours of the attack. That probably made a big difference in limiting how much damage the attackers were able to do.<br />
<br />
Hopefully the company will continue to conduct effective incident monitoring and response just in case the Morris worm does rear its ancient head.Bruce K. Marshallhttp://www.blogger.com/profile/07397177700712500000noreply@blogger.com0tag:blogger.com,1999:blog-2920277117928389647.post-67122376394917758112013-07-31T19:55:00.001-05:002013-07-31T19:55:27.131-05:00A Review of Real World Security Questions & AnswersYesterday I delivered my presentation titled A Review of Real World Security Questions and Answers at <a href="http://www.passwordscon.org/" target="_blank">PasswordsCon 13</a>. I have written about security questions (AKA <a href="http://blog.passwordresearch.com/2007/07/tips-for-avoiding-bad-authentication.html" target="_blank">challenge questions</a>) before, but this presentation is based on my analysis of thousands of actual user choices that were included in hacker database dumps from three different organizations this past year.<br />
<br />
We don't often have an opportunity to see how people are actually using security questions outside of controlled surveys, so I was thrilled to dig into the data to see what additional insights it offered about their strengths and weaknesses. Hopefully you will find it to be a useful resource when making decisions about the use of security questions in your own organization.<br />
<br />
You can find a copy of my presentation slides with my analysis at <a href="http://www.passwordresearch.com/securityqs.html">www.passwordresearch.com/securityqs.html</a>. If you would like to talk about these findings you are welcome to contact me through <a href="http://www.passwordresearch.com/about.html" target="_blank">email</a> or on Twitter <a href="http://www.twitter.com/PwdRsch" target="_blank">@PwdRsch</a>. You can also post your comments or questions on this blog entry.<br />
<br />
<br />Bruce K. Marshallhttp://www.blogger.com/profile/07397177700712500000noreply@blogger.com0tag:blogger.com,1999:blog-2920277117928389647.post-22044383103294899202013-02-07T00:12:00.002-06:002013-02-07T08:52:28.707-06:00Passwords Found in the Wild for January 2013<div style="margin-bottom: 0in;">
Studying the <a href="http://blog.passwordresearch.com/2013/01/passwords-found-in-wild-for-december.html" target="_blank">passwords dumped on the Internet</a> by hackers back in December provided a good opportunity for me to measure the scope of the
problem. Following that experience I decided to collect and
correlate some new information when analyzing password dumps from
January.</div>
<div style="margin-bottom: 0in;">
<br /></div>
<h4 style="margin-bottom: 0in;">
<b>Overview of Password Dumps</b></h4>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
Last month I found 110 password dumps
which met my criteria* for analysis, down from 154 in December. A
few of the dumps contained data from multiple sites. There were 90
specific organizations or domains named as the source of the
passwords. The remaining dumps didn't identify the source of their
data, or were gathered from multiple personal computers instead of
from a centralized web site.</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
From this collection, 40 dumps
consisted primarily of plaintext passwords, exposing roughly 61,000
passwords (36% of the monthly total). Another 64 dumps primarily
contained hashed passwords, adding approximately 101,000 passwords
(59% of the total). Six more dumps had a mixture of plaintext and
hashed passwords, accounting for 9,000 passwords (5% of the total).</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
Compared to 450,000 passwords dumped in
December, this month's total of 170,000 passwords was significantly
lower. A contributing factor to this was the smaller number of
dumps, but maybe more importantly there also tended to be fewer large
password dumps. This month only had two dumps containing more than
10,000 passwords, while last month had 17.</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
I wasn't really surprised to see this
result. The number of sites that are compromised and the number of
passwords they disclose will always change based on what is getting
hacked that month and how large the vulnerable sites happen to be.</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
Over time a baseline average of 150,000
- 300,000 passwords dumped each month might emerge, but this number
would skyrocket every time a large site was affected by a security
breach. In June of 2012 we watched LinkedIn lose 6.5 million
passwords and eHarmony lose around 1.5 million. The next month
450,000 passwords were leaked from Yahoo Voices. Just this past
Friday Twitter announced a forced password change for around 250,000
users whose password hashes may have been accessed by hackers
(although these have yet to be publicly dumped).</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
There were 40 different hackers or
hacker groups claiming credit for January's password dumps, and more
hackers that chose to dump their data anonymously. So even the
retirement, capture, or poor motivation of any particular hacker
seems unlikely to have a large impact in the flow of monthly password
dumps.</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
The biggest deterrent to future
password dumps is more likely to be improvements in the security of
the code and development frameworks used by the vulnerable sites, or
a widespread adoption of specific security countermeasures (e.g. web
application firewalls or intrusion prevention systems). This brings
us to the subject of what types of sites I found to be vulnerable
today.</div>
<div style="margin-bottom: 0in;">
<br /></div>
<h4 style="margin-bottom: 0in;">
<b>Sites Vulnerable to Password Dumps</b></h4>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
In January I decided to visit all the
sites named in the password dumps and gather information on the
software coding language they used, the category of the function they
served, and the country in which they were hosted. I hoped this might
provide some further insight on whether these attacks were targeted
in any way or simply opportunistic.</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
SQL injection attacks appear to be the
primary supplier of the database dumps containing passwords. Many of
the dumps include actual output from the tools (like <a href="http://www.itsecteam.com/products/havij-v116-advanced-sql-injection/index.html" target="_blank">Havij</a>)
that hackers can use to automate the extraction of database contents.
This seemed pretty intuitive since SQL injection is a common web
application vulnerability and one that may not require hackers to
gain any other illicit access on the targeted site.</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
What did surprise me was that the
majority of the 87 named sites targeted with password dumps were
developed using the PHP programming language, as shown in the
following chart.</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgGntaMfwh7LAty3kkR8my0qyz-UF60QVG4gMZv4xjYEFAlz0ToqR7iiP0DPr6zo3Xf9qKGQCoXZs5UBpOakEA81SGxGF1UPBK2IPiq8RPWk325tIY6Pa55jB8kQmD_EP64HZS37pWEmz4/s1600/SiteCodingJan2013.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img alt="Coding language used by sites experiencing password dumps in January 2013" border="0" height="256" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgGntaMfwh7LAty3kkR8my0qyz-UF60QVG4gMZv4xjYEFAlz0ToqR7iiP0DPr6zo3Xf9qKGQCoXZs5UBpOakEA81SGxGF1UPBK2IPiq8RPWk325tIY6Pa55jB8kQmD_EP64HZS37pWEmz4/s1600/SiteCodingJan2013.png" title="" width="400" /></a></div>
<div style="margin-bottom: 0in;">
</div>
<div style="margin-bottom: 0in;">
<a href="http://news.netcraft.com/archives/2013/01/31/php-just-grows-grows.html" target="_blank">Netcraft's Web Server Survey</a> for this
same
month
shows that 39% of all web sites (around 244 million) are running PHP.
While that is a large portion of the Internet, the market share by
itself doesn't seem to justify PHP sites making up 91% of the total.
After all, sites using ASP and JSP can be just as vulnerable to SQL
injection attacks as PHP. If I didn't know that SQL injection was
the primary attack method I would suspect that hackers were
exploiting some PHP-specific vulnerabilities.</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
</div>
<div style="margin-bottom: 0in;">
A more likely explanation is that the
popularity of the language has led to the rapid deployment of PHP
sites and PHP-based content management systems (CMS) by people who
lack an education in web application security. Even though the risk
of <a href="http://php.net/manual/en/security.database.sql-injection.php" target="_blank">SQL injection in PHP</a> should be fairly well understood, some
organizations still end up deploying code that doesn't implement
proper security controls.</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
Interestingly enough, I found that one
of the organizations suffering a January password dump had actually
showed up previously in a hacker's report of sites vulnerable to SQL
injection posted on Pastebin.com over 6 months ago. So either they
never learned they were vulnerable in the subsequent months or were
unable to completely fix the problem before it was exploited to dump
their entire user database.<br />
<br />
<div style="margin-bottom: 0in;">
Another possible explanation is that
some of these sites might be unintentionally allowing attackers to
connect directly to the site database and download records that way.
This should be prevented by host firewall segmentation and proper
database authentication, but sites may have been deployed
without these precautions. I see evidence within the posted password
dump files that this is happening, but I believe it is secondary to the more popular SQL injection attacks.</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
While all software developers and web
admins should learn about SQL Injection prevention and other secure
site management practices, it appears that the PHP community needs
the most help catching up.</div>
</div>
<div style="margin-bottom: 0in;">
<br /></div>
<h4 style="margin-bottom: 0in;">
<b>Categories of Targeted Sites</b></h4>
<div style="font-weight: normal; margin-bottom: 0in;">
<br /></div>
<div style="font-weight: normal; margin-bottom: 0in;">
When I visited
these vulnerable sites I also assigned them a category based on the
site's purpose. Most of these category labels should be self
explanatory, but I'll provide a description for a few of them.</div>
<div style="font-weight: normal; margin-bottom: 0in;">
<br /></div>
<div style="font-weight: normal; margin-bottom: 0in;">
Education sites
were mainly universities, although there was one primary school.
Business sites were a corporate web presence that mainly published
data and didn't offer online services to customers. Entertainment
sites could be a discussion forum or a site sharing information on a
specific topic (e.g. movies or sports).</div>
<div style="font-weight: normal; margin-bottom: 0in;">
<br /></div>
<div style="font-weight: normal; margin-bottom: 0in;">
An Online Store
was a business site where customers could make purchases. This type
of site would be particularly valuable to attackers looking to
capture stored billing information or to order merchandise and charge
it to customers. As mentioned last month, sites like this often
don't make it into public password dumps because attackers can <a href="http://krebsonsecurity.com/2012/12/exploring-the-market-for-stolen-passwords/" target="_blank">sell<b> </b>the account data</a>
in the underground marketplace.</div>
<div style="font-weight: normal; margin-bottom: 0in;">
<br /></div>
<div style="font-weight: normal; margin-bottom: 0in;">
Info Services are
the sites that sell information as a single-use or subscription
service. These sites could also be valuable to attackers,
depending on what type of data they make available to customers. Finance sites
are banks, credit unions, or other related institutions, but in this
month's case it was a single investment firm.</div>
<div style="font-weight: normal; margin-bottom: 0in;">
<br /></div>
<div style="font-weight: normal; margin-bottom: 0in;">
The chart below
shows how many sites matched each category in the January password
dumps.</div>
<div style="font-weight: normal; margin-bottom: 0in;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhQ0yFNfx5WlpjUCy89evDbMmoCw0TVhpTrzonny5-vbyR_ikbS0CamN42mkir5cLCOzy-8uk-pXxczp17wM9W_ZMesz5Dl8u447BqWce_pbMcaBC2WMdL17dnM6ewXN0T9UZ_io-eOEAA/s1600/SiteCategoriesJan2013.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img alt="Category of sites experiencing password dumps in January 2013" border="0" height="225" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhQ0yFNfx5WlpjUCy89evDbMmoCw0TVhpTrzonny5-vbyR_ikbS0CamN42mkir5cLCOzy-8uk-pXxczp17wM9W_ZMesz5Dl8u447BqWce_pbMcaBC2WMdL17dnM6ewXN0T9UZ_io-eOEAA/s1600/SiteCategoriesJan2013.png" title="" width="400" /></a></div>
<div style="font-weight: normal; margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
I didn't really have many preconceived
ideas about the categories of sites I expected to see targeted.
Government, Business, Medical, Education, News, and Political
certainly make sense if the attacker hopes to gain media attention
with their data dump. </div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
The Online Stores, Info Services, and
Financial sites make sense if the attacker hoped to make a financial
gain from the attack. Although going after these sites could also
certainly just be for bragging rights.</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
There is probably some ratio of
opportunistic and targeted attacks in this mix, but it is difficult
to detect unless the hackers specifically outline their motivations
in the dump descriptions.</div>
<div style="margin-bottom: 0in;">
<br /></div>
<h4 style="margin-bottom: 0in;">
<b>Countries Hosting the Targeted Sites</b></h4>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
I was able to identify the country of
origin for 96 of the January password dumps. There were 35 different
countries represented in that total. The top 10 countries that
experienced the most password dumps are shown in the chart below.</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgIMMSyvI_d-a4BlnLlVWeLqOSreTXQJJP2Q4a9rsmyCFRBYQkO6QWqZeCMnGCuEZXXexZsn9UYyW2rzsa7XQp9Rpic40UItuD1-Bk9GHf3RHIQA_MDdaXrKVijauGDjSmAl-EZaTE43Ss/s1600/SiteCountriesJan2013.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img alt="Country hosting the sites experiencing password dumps in January 2013" border="0" height="235" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgIMMSyvI_d-a4BlnLlVWeLqOSreTXQJJP2Q4a9rsmyCFRBYQkO6QWqZeCMnGCuEZXXexZsn9UYyW2rzsa7XQp9Rpic40UItuD1-Bk9GHf3RHIQA_MDdaXrKVijauGDjSmAl-EZaTE43Ss/s1600/SiteCountriesJan2013.png" title="" width="400" /></a></div>
<div style="margin-bottom: 0in;">
</div>
<div style="margin-bottom: 0in;">
Seven other countries tied the
Philippines with two vulnerable sites each. South Africa was given a
bit more attention in January than normal due to one hacker group
specifically targeting organizations in that country as part of a
political statement.</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
Another observation was that half of
the vulnerable sites in India were Education category sites. They
were the only country that had such a large percentage of their sites
in the same category. This might indicate greater web site security
problems at universities in India, or it could just be chance.</div>
<br />
<h4 style="margin-bottom: 0in;">
<b>Impacts on Users of Targeted Sites</b></h4>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
At least some users of the hacked sites
are likely to experience problems as a result of these password
dumps. If passwords were stored in a plaintext format then any
account is vulnerable to misuse by unauthorized individuals. Even if
hashed, password cracking software can produce the plaintext
passwords fairly quickly for all but the stronger passwords. Whether
hackers care to use these stolen credentials will depend partially on
what the account can be used for and partially on how motivated they
are to annoy users.</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
Some web sites use an email address for
the username, or record the email address during the account
registration process. Email addresses of users were found in 96
(87%) of the analyzed password dumps in January.</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
The use of email addresses isn't
necessarily a problem by itself, but the reality of user password
practices can result in email address leaks endangering their
identities on other Internet sites. If one organization leaks email
addresses and passwords this allows attackers to try those
credentials elsewhere. In fact, hackers have developed software
tools that automate the process of trying discovered email and
password combinations against a list of popular web sites.</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
Password reuse makes this a real
problem, although mainly for the users and not necessarily for the
site that was vulnerable to the password dump in the first place.
Even if a user chose a stronger password to reuse, it only takes one
site storing that password in plaintext to potentially expose all of
their accounts.</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
My suggestion to users is that
passwords should never be reused across any sites where you would
care if your account gets hacked. Always choose a strong and unique
password for each site and then store it in a password manager if you
are concerned about forgetting it.</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
Web sites often can't do much to
prevent password reuse other than enforcing good password selection
controls that might eliminate the worst of the reused passwords.
However, they can make sure that they use adequate password hashing
and salting techniques that make the task of cracking user passwords
much more difficult for hackers. Sites should also <a href="http://blog.twitter.com/2013/02/keeping-our-users-secure.html" target="_blank">notify users when a database breach is detected</a> and warn them to change their password
anywhere else it was used, in addition to forcing a change on the
hacked site itself.</div>
<div style="margin-bottom: 0in;">
<br /></div>
<h4 style="margin-bottom: 0in;">
<b>Conclusion</b></h4>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
I wasn't able to complete my analysis
of all the information provided by the password dumps in January, but
I'll continue to work on it and will post new results here on the
blog. In the meantime, if you have any questions or comments leave
them below, or contact me on Twitter <a href="http://www.twitter.com/PwdRsch" target="_blank">@PwdRsch</a>.</div>
<div style="margin-bottom: 0in;">
<br /></div>
<h4 style="margin-bottom: 0in;">
<b>* Study Methodology</b></h4>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
I monitored Twitter and other sites for
notices that a data dump had been publicly posted. Some data dumps
contained user or customer information but not passwords. Others
contained only the administrator password or the passwords of a very
limited number of users. I ignored these and focused only on sources
that contained passwords (hashed or plaintext) of at least a dozen or
more users.</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
I also attempted to eliminate duplicate
dumps, a practice where one hacker copies a full or partial dump from
someone else and reposts it as their own. Sometimes these dumps are
from the same month and sometimes they are from previous months.</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
In a few cases the dump poster noted
that they had included only a subset of the available user passwords.
While I didn't count the unposted passwords, we should assume that
the attacker had access to the complete user database, which would
increase the total number of passwords exposed.</div>
<div style="margin-bottom: 0in;">
<br /></div>
<div style="margin-bottom: 0in;">
When reviewing these figures keep in
mind that they account only for the publicly posted data which I was
able to discover. Hackers certainly compromised the passwords of
other sites and kept this activity secret, or shared the data over
more private channels.</div>
<div style="margin-bottom: 0in;">
<br /></div>
Bruce K. Marshallhttp://www.blogger.com/profile/07397177700712500000noreply@blogger.com2tag:blogger.com,1999:blog-2920277117928389647.post-78450705277141907082013-01-07T00:39:00.000-06:002013-01-07T09:41:28.400-06:00Passwords Found in the Wild for December 2012In the late 1990's when I started analyzing passwords it was much harder to find samples to review. My password collection routine consisted mainly of begging colleagues to share data or volunteering to perform the cracking for their security assessments. Occasionally I would get lucky and find a publicly readable password file on the Internet. Then I could dedicate a computer for several months to cracking each password database because it would certainly take at least that long before another sample showed up.<br />
<br />
Today I find that I am actually overwhelmed with the opportunities to gather passwords. The raw number of Internet sites that register users and collect their passwords is huge. Correspondingly, the number of these sites that are susceptible to SQL injection or other vulnerabilities that allow attackers to extract their user databases has also grown. Hackers are regularly exploiting these flaws and publishing password dumps to embarrass companies, to attract attention to their causes, or to simply stroke their egos.<br />
<br />
I decided to monitor password dumps in December 2012 to get a better idea of how widespread this practice has become. I monitored several sources (though mainly the Pastebin.com web site) for announcements of dumps and analyzed the data posted.<br />
<h4>
Study Methodology</h4>
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; margin-left: 1em; text-align: right;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgP2asLqg5_GHzxx2iD7pWaYabtjArKXeNvGeysoBdfpPEP3zTzkMVqNgWAOLXZDHU6r9mtgzxeR1tdkyIgmoc7vFNcUv9Lvp1oIP7vWM6MeR6DfNvX8AyCuEUbZ3DFAaC5DUWmqwmKXqA/s1600/PasswordDumpSpreadsheet.png" imageanchor="1" style="clear: right; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgP2asLqg5_GHzxx2iD7pWaYabtjArKXeNvGeysoBdfpPEP3zTzkMVqNgWAOLXZDHU6r9mtgzxeR1tdkyIgmoc7vFNcUv9Lvp1oIP7vWM6MeR6DfNvX8AyCuEUbZ3DFAaC5DUWmqwmKXqA/s200/PasswordDumpSpreadsheet.png" height="143" width="200" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Snippet of Password Dump Tracking Data</td><td class="tr-caption" style="text-align: center;"><br /></td></tr>
</tbody></table>
Some data dumps contained user or customer information but not passwords. Others contained only the administrator password or the passwords of a very limited number of users. I ignored these and focused only on sources that contained passwords (hashed or plaintext) of at least a dozen or more users. I also attempted to eliminate duplicate dumps, a practice where one hacker copies a full or partial dump from someone else and reposts it as their own.<br />
<br />
In some cases the dump poster also noted that they included only a subset of the available user passwords. However, we should assume that the attacker had access to the complete user database, which would increase the actual number of passwords exposed.<br />
<br />
When reviewing these figures keep in mind that they account only for the publicly posted data of which I was made aware. Hackers certainly compromised the passwords of other sites and kept this activity secret, or shared the data over more private channels. Brian Krebs covered the underground marketplace for the more valuable passwords in his recent <a href="http://krebsonsecurity.com/2012/12/exploring-the-market-for-stolen-passwords/" target="_blank">blog post</a>.<br />
<h4>
Password Dump Findings</h4>
In December I found 154 dumps which met my criteria for analysis. A few of the dumps contained data from multiple sites. They named more than 125 different organizations and domains as the source of the leaks. Passwords belonged to users at businesses, governments, schools, industry groups, and discussion forums. Some dumps didn't identify the source of their data, or were gathered from multiple personal computers instead of from a centralized web site.<br />
<br />
From this collection, 66 dumps consisted primarily of plaintext passwords, exposing roughly 221,000 passwords. Another 82 dumps primarily contained hashed passwords, adding approximately 222,000 passwords to the count. So while the number of hashed password dumps was greater than the plaintext dumps, the number of passwords exposed was nearly equal. Six more dumps had a mixture of plaintext and hashed passwords, but only accounted for 6,000 passwords.<br />
<br />
Altogether, I found that almost 450,000 passwords were publicly exposed during the month. There were 103 dumps containing less than 1,000 passwords, and 17 dumps containing more than 10,000 passwords. About 184,000 passwords (41% of the total) came from several dumps simultaneously released as part of Team GhostShell's Project WhiteFox on December 10th.<br />
<br />
Finding that half of the exposed passwords lack the security provided by basic password hashing is disappointing. While some of the affected sites likely have low security requirements, storing only password hashes is a pretty standard security practice that should be followed by almost every site.<br />
<br />
Without password hashing both the poorly and well constructed passwords are exposed during leaks like these. A user may think their password is secure only to find that their account has been compromised due to insecure password storage that was beyond their control.<br />
<br />
Even hashed passwords can only offer resistance against attacks once they have been stolen from an organization. Password crackers have become faster and more proficient at trying common words, names, phrases, and other combinations of guesses that can disclose a password after it has been hashed.<br />
<h4>
Conclusion</h4>
My feelings are mixed when it comes to the results of this study. On one hand I'm frustrated with the security vulnerabilities that continue to plague many Internet sites, and on the other hand I'm eager to see what wisdom is provided by examining these leaked passwords. The wide variety of passwords from these different sources allows researchers like me to pick and choose the password samples that seem most interesting or likely to produce the information we seek.<br />
<br />
So these days instead of begging for passwords I'm finding myself begging for help to sort through all the password data that is available to me.Bruce K. Marshallhttp://www.blogger.com/profile/07397177700712500000noreply@blogger.com2tag:blogger.com,1999:blog-2920277117928389647.post-21552300792841995082009-07-13T12:23:00.002-05:002009-07-13T12:26:12.050-05:00Finding the humor in changing your passwordOn the lighter side of things, here's a reminder of what users may experience when it comes to changing their passwords:<br /><a href="http://www.washingtonpost.com/wp-dyn/content/article/2009/07/12/AR2009071202012.html?hpid=sec-metro">http://www.washingtonpost.com/wp-dyn/content/article/2009/07/12/AR2009071202012.html?hpid=sec-metro</a>Bruce K. Marshallhttp://www.blogger.com/profile/07397177700712500000noreply@blogger.com1tag:blogger.com,1999:blog-2920277117928389647.post-57731487979028971422007-09-10T14:14:00.000-05:002007-09-18T11:20:28.857-05:00Embassy password hacker reveals his techniqueA Swedish hacker calling himself "DEranged" attracted media attention over the past couple weeks by posting a list of 100 government email usernames and passwords. His list included email accounts used by embassy officials from India, Russia, Iran, Hong Kong, and others. A <a href="http://www.infoworld.com/article/07/08/30/Hacks-hit-embassy-government-e-mail-accounts-worldwide_1.html" target="_blank">few journalists</a> verified that these credentials could indeed be used to access private email.<br /><br />At the time of <a href="http://www.derangedsecurity.com/deranged-gives-you-100-passwords-to-governments-embassies/" target="_blank">his original disclosure</a> DEranged (his real name is Dan Egerstad) withheld details on how he came into possession of the passwords, instead writing that "there is no exploit to publish, no vendor to contact". Today he posted an <a href="http://www.derangedsecurity.com/time-to-reveal%E2%80%A6/" target="_blank">entry on his blog</a> describing how he used newer software to exploit an older problem.<br /><br />Egerstad established several computers as nodes in the <a href="http://tor.eff.org/" target="_blank">Tor network</a>. As a part of this network, these computers would act as intermediary routers in the delivery of Internet traffic. By routing this traffic Egerstad also gained the capacity to capture and analyze any unencrypted packets sent through his systems. He then used this access to collect thousands of usernames and passwords transmitted to email servers in the clear.<br /><br />I will not praise Egerstad due to his poor ethics in disclosing passwords in the manner that he did, but ultimately he is right in pointing out the serious shortcomings of protocols that still transmit unencrypted passwords.<br /><br />There have been secure alternatives to POP3, such as POP3 over SSL, for some time. However, many companies and service providers fail to offer them, let alone make them the default setting. Organizations can only justify this continued practice because of the difficulty in detecting password capturing attacks. IT personnel can avoid responsibility by dismissing password thefts as a user problem resulting from phishing attacks or software trojans. This is an unacceptable response.<br /><br />With the growing number of mobile users and wireless networks, the opportunities for password capture attacks will increase. If you are using POP3, Telnet, HTTP, FTP, or any other unencrypted protocol for transmitting passwords, look into alternatives today. People with more dangerous agendas than Egerstad will be watching to see if you do.Bruce K. Marshallhttp://www.blogger.com/profile/07397177700712500000noreply@blogger.com2tag:blogger.com,1999:blog-2920277117928389647.post-17902837332528564142007-09-04T14:35:00.000-05:002007-09-06T15:25:37.580-05:00My advice to users on storing written passwordsGiving blanket advice on creating, using, and securing passwords is always a worry of mine. Life has taught me that advice is sometimes interpreted or adapted in such a way that it is, at best, rendered less useful or, at worse, made downright dangerous. This is more likely to happen as the subject knowledge gap expands between the advice giver and advice receiver.<br /><br />So, it was with some hesitancy that I shared my advice on writing down passwords with a reporter a few weeks ago. To his credit, the quote he included in <a href="http://online.wsj.com/article/SB118788934156306767.html?mod=OATE" target="_blank">his article</a> was intact and hadn't fallen victim to creative rephrasing. However, I knew that some of his readers would be absorbing my advice from a non-technical perspective and I worried about their interpretation. I would like to use this blog post to explain this advice beyond the few lines available to me in his column.<br /><br />Let's start with the quote: "This is controversial advice in some circles, but I advise people to write down their passwords. If it is a password you are going to use every day, keep it on a slip of paper in your wallet. Don't write anything else down on the paper that could identify where you are using the password or your username."<br /><br />I believe this is sound advice, although I want to emphasize the importance of writing passwords on a blank piece of paper with no other identifying information. Once during an introduction I was handed a business card which included a string of characters written on the back. The string struck me as particularly password-like. I can only assume the person had written it down and forgotten that this particular card wasn't meant to be given away.<br /><br />What didn't make it into the article was my subsequent comment that a password in your wallet should serve only as a temporary memory aid. Within a week or two of use, a password should be committed to long term memory, reducing the likelihood of it being forgotten. This is when the wallet copy should be destroyed and the password archived in a more secure location.<br /><br />I will avoid getting into specific password storage software in this post. There are good open source and commercial alternatives available. There are also Trojans horses posing as password managers that would love nothing more than to capture your secrets and relay them back across the Internet to their criminal masters. Take time to check out the reputation of any password software before installing it.<br /><br />I recommend writing down passwords to improve their <a href="http://www.passwordresearch.com/core.html">usability and affordability</a> by reducing the number of times a forgotten password results in an IT support call. However, the biggest benefit is the chance to encourage better password selection.<br /><br />One of the major factors that impede good password choices is a user's fear that they won't remember a well constructed password. Nobody wants to be stuck staring at a password prompt and cursing their decision to finally come up with a good password. Even worse is the feeling of stupidity they experience when they have to call someone and admit to forgetting their password.<br /><br />When a person has a reliable written record of a password it takes away a lot of this fear by letting them serve as their own first line of support.<br /><br />If you are willing to publicly support this practice in your organization, I encourage you to associate this freedom with a requirement for stronger password security. Educate users on how to construct hard-to-guess passwords. Implement technical controls that force new passwords to meet minimum requirements. Make sure that passwords are changed on a regular basis. Finally, emphasize that these written or stored passwords must be very well protected.<br /><br />Does this practice seem practical for the people you work with, or am I only encouraging a new generation of people to sticky-note passwords by their computers?Bruce K. Marshallhttp://www.blogger.com/profile/07397177700712500000noreply@blogger.com5tag:blogger.com,1999:blog-2920277117928389647.post-25085632215030870612007-08-28T10:03:00.000-05:002007-09-04T15:01:31.297-05:00How password policy requirements impact possible password choicesA recent discussion on a <a href="http://www.securityfocus.com/archive/88/476610/30/30/threaded" target="_blank">SecurityFocus.com mailing list</a> raised a concern about password policies that I hadn't previously given much thought to. The post author commented that he wanted to enforce a policy that required passwords to have lowercase, uppercase, number, and symbol characters. By this he meant every password must have at least one character from each of these characters sets. One reader responded that by requiring the use of all four character sets he would reduce the total number of possible passwords, causing a negative impact on password security.<br /><br />Instinctively I knew the claim about reducing password possibilities was right, but I dismissed the security impacts as insignificant. After all, with 95 standard characters within that character pool to choose from, the total number of password possibilities is massive. Unfortunately "massive" doesn't really provide much perspective on how negative the impact could be. To quantify the impact I decided to calculate the actual effects on password possibilities.<br /><br />I started with a set password length of 7 characters, giving us 95^7 (or 6.98 x 10^13) total possible passwords that users can create without any specific character requirements. This gave me the unrestricted total. I then needed to figure out how many of these passwords would meet the restricted requirements of having lowercase, uppercase, number, and symbol characters within them.<br /><br />Following some different approaches at number crunching I found that there may not be an easy formula for calculating the quantity of restricted password possibilities. The easiest approach seemed to be counting the number of passwords not meeting the criteria and then subtracting them from the unrestricted total. While not math intensive, this approach does take some fancy spreadsheet formulas. If you have a burning desire to see the numbers yourself, you can check out the resulting <a href="http://www.passwordresearch.com/files/Password Pool Possibilities - PUBLIC.xls">Excel spreadsheet I created</a>.<br /><br />When I compared the restricted and unrestricted password possibilities I was in for a bit of a shock. It turns out that for 7 character passwords the restricted requirements would eliminate about 63% (or 4.4 x 10^13) of the total password possibilities! So much for an insignificant impact.<br /><br />I applied this technique for several different lengths of passwords to see how the length changed the results. The longer the password became, the more the percentage of eliminated passwords shrunk. The restriction eliminated 54% of 8 character passwords. With 10 and 12 character passwords only 41% and 31%, respectively, were eliminated. These losses still amount to sizeable chunks.<br /><br />This led me to evaluate the impacts of the normal Microsoft Windows password complexity requirements. Enabling this security policy forces users to choose a password made up from only three of the four character types. For a 7 character password this still amounted to a 9% reduction in possible passwords.<br /><br />So, numerically we've established the impacts of different password policies, but how should these numbers affect our decisions to enforce such policies?<br /><br />If we consider password cracking our biggest threat then we must consider how knowledge of the password policy might save an attacker time avoiding unacceptable passwords. Fortunately, real-time brute force cracking isn't terribly compatible with this approach. In the time it takes for cracking software to evaluate whether a password guess meets the policy it could have just tried the password. So no effort is eliminated in this scenario.<br /><br />However, a rainbows tables cracking approach can benefit from policy knowledge. An attacker could create a rainbow table consisting of only the passwords that meet a particular password policy. As a matter of fact, <a href="http://www.antsight.com/zsl/rainbowcrack/" target="_blank">attackers do that today</a> by generating and sharing rainbow tables consisting of the most common password character sets.<br /><br />While bad guys could technically implement this attack for complex passwords, it would be one of last resorts. So few environments require passwords containing the four different character sets that attackers have little reason to generate the rainbow tables. It is still much more rewarding for them to focus on cracking passwords like "muffins" instead of "b@n4Na5". <br /><br />More importantly, creating just the rainbow tables needed for our restricted password pool of 7 character passwords would require hundreds of terabytes of disk space. Yes, I did the math. Few attackers have this level of resources available to them.<br /><br />We have always made sacrifices like this when instituting password policies. By establishing a minimum password length we, by definition, eliminate all possible passwords of a shorter length. Nonetheless, we know we are making a general improvement in overall password security by removing the shorter, and thus easier to crack, passwords.<br /><br />When it comes to password complexity we have to consider the attack significance along with the mathematical significance. In reality, there are situations where enforcing <a href="http://archives.neohapsis.com/archives/nfr-wizards/1998/09/0020.html" target="_blank">specific password restrictions</a> is a very bad idea. However, this is the exception rather than the rule.<br /><br />I don't believe that enforcing either normal Windows password complexity policy or the even more restrictive 4 character set composition requirement should worry you when paired with a minimum password length of 7 characters. The loss of possible passwords in these cases are greatly outweighed by the benefits of eliminating a large number of poor password choices. From my perspective, those changes have a positive impact on security.Bruce K. Marshallhttp://www.blogger.com/profile/07397177700712500000noreply@blogger.com1tag:blogger.com,1999:blog-2920277117928389647.post-8536414458834517532007-08-16T00:33:00.000-05:002007-08-23T10:53:13.316-05:00We know about password attacks in KansasI was making a dent in a sink full of dishes tonight and half listening to the TV when a show caught my interest. Dateline NBC was airing a segment on the disappearance of John Elwin during a business trip. Apparently his girlfriend, Kirsten Flood, wasn't initially having luck interesting authorities in a search for clues about the whereabouts of Mr. Elwin. Frustrated, she engaged a friend, Denise Tripoli, with "experience in Internet security" to help.<br /><br />The following excerpt comes from the <a href="http://www.msnbc.msn.com/id/20281102/" target="_blank">show's transcript</a>: <br /><br /> If only she could hack into Elwin's e-mail account, they might discover where he was.<br /><br /> The two women wracked their brains trying to guess at a pass code that would give them access.<br /><br /> <span style="font-weight:bold;">FLOOD</span>: [We tried] his birthday, his social security number. And I just kept going down the list until I hit it.<br /><br /> <span style="font-weight:bold;">FLOOD</span>: And lo and behold, we got into it.<br /><br /> <span style="font-weight:bold;">BOB MORRISON</span>: What did you find there?<br /><br /> <span style="font-weight:bold;">TRIPOLI</span>: We broke into his account at eleven o'clock at night, and I was up till three in the morning, looking through every e-mail. And I was very disturbed by what I saw.<br /><br />I certainly won't pretend that I would avoid this temptation if one of my friends or family members went missing and I had exhausted other options. Nonetheless, I was a little disturbed by the casual explanation of how these women broke the law to gain access to Mr. Elwin's email account. In my opinion, reporting this part of the story in this manner trivializes the ethical and legal implications of getting into another person's email account.<br /><br />You would expect that a news organization so eager to <a href="http://blogs.zdnet.com/Ou/?p=653" target="_blank">expose the secret underworld of hackers</a> would act more responsibly.Bruce K. Marshallhttp://www.blogger.com/profile/07397177700712500000noreply@blogger.com0tag:blogger.com,1999:blog-2920277117928389647.post-82138204237656740862007-08-15T10:37:00.001-05:002011-05-25T10:36:54.818-05:00Automating analysis of authentication system weaknessesMost knowledge-based authenticators run the risk of poor uniqueness when they rely on users to generate or select the secret information. The human mind tends to seek order in the knowledge we acquire and store. This means that you, I, and a few billion others generate similar secrets for authentication.<br /><br />Seeing as how I make a living off applying my knowledge I don't complain about this natural phenomenon. However, I do occasionally wish that more authentication system designers took it into consideration. While we can't expect them to overcome this reality, they do need to anticipate it and avoid design or implementation decisions that magnify problems.<br /><br />For example, <a href="http://www.passwordresearch.com/papers/paper119.html">PassPoints</a> is a knowledge-based graphical password system developed a couple of years ago. This system presents users with a picture and authenticates them by analyzing where they click within the image. Users choose and click on their own series of points during the authentication enrollment process. During subsequent authentications, only the legitimate user should know where to click within an image.<br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://www.usenix.org/events/sec07/tech/full_papers/thorpe/thorpe_html/C_pool.png"><img style="float: right; margin: 0pt 0pt 10px 10px; cursor: pointer; width: 330px; height: 246px;" src="http://www.usenix.org/events/sec07/tech/full_papers/thorpe/thorpe_html/C_pool.png" alt="" border="0" /></a><br />Of course, the security of the system relies on the premise that there aren't a limited number of predictable click points within the image. Good old human brains will sometimes look at the same picture and click on the same points. Our eyes may all be drawn to the fire hydrant, building corner, or stunning brunette. With graphical passwords this appears to be dependent on what is depicted in a particular image. The more predictable the click points are within a picture, the less useful that picture is for uniquely authenticating users.<br /><br />So I was pleased to see a recent paper where the authors not only recognize this challenge, but also attempt to automatically evaluate an image for predictable points. <a href="http://www.passwordresearch.com/papers/paper156.html">Modeling User Choice in the PassPoints Graphical Password Scheme</a> is an update from several of the original PassPoints researchers explaining how new software could sometimes accurately predict (70% - 80% in their test case) clickable points within an image. In turn, this software could be used to eliminate images that have too few likely-to-be-clicked points.<br /><br />I hope that this trend of investigating and developing quality controls for authentication systems continues.Bruce K. Marshallhttp://www.blogger.com/profile/07397177700712500000noreply@blogger.com0tag:blogger.com,1999:blog-2920277117928389647.post-28407602735805552142007-08-06T11:31:00.000-05:002007-08-06T11:38:47.158-05:00Banks fail to meet FFIEC multi-factor authentication requirementsAccording to a recent study, only 4% of financial institutions are actually meeting the FFIEC requirements for multi-factor authentication. Many of the others are relying on challenge questions or other risk-based authentication approaches that ultimately only provide single-factor security.<br /><br />I’ve shared more on my analysis of this problem and its implications in this <a href="http://blog.securityps.com/2007/08/banks-fail-to-meet-ffiec-multi-factor.html" target="_blank">Security PS blog entry</a>.Bruce K. Marshallhttp://www.blogger.com/profile/07397177700712500000noreply@blogger.com0tag:blogger.com,1999:blog-2920277117928389647.post-83486372252173612992007-07-30T23:08:00.000-05:002007-08-11T15:33:16.485-05:00Nevada governor's email password is only a click awayIt may not surprise you to discover that the Nevada governor doesn't send out his own weekly email updates. However, you should be alarmed that this task might not be limited to his trusted staff.<br /><br />Declan McCullagh posted <a href="http://news.com.com/8301-10784_3-9747705-7.html" target="_blank">this news article</a> about finding the governor's password in an Internet accessible Word document. The document contained step-by-step instructions for sending out email using the governor’s account. At the appropriate places, the account username and password for the governor were listed.<br /><br />Whether anyone on the Internet could have logged in and sent mail as the governor is an interesting question, but I certainly assume that unauthorized folks within the state capital (possibly from opposition parties) could have. If a malicious email had been sent out, it would take more than a quick retraction to undo the damage.<br /><br />The main lesson to take away from this incident is that your passwords should almost never be included in procedural documents. Instead, these appropriate steps should refer the reader to the appropriate secure password storage location (like an encrypted password safe) or to an employee who can properly limit password distribution to authorized personnel. Then your authentication system won't rely entirely on how well people protect an unencrypted electronic document.Bruce K. Marshallhttp://www.blogger.com/profile/07397177700712500000noreply@blogger.com0tag:blogger.com,1999:blog-2920277117928389647.post-3549046508646922392007-07-30T22:09:00.000-05:002007-08-03T13:17:44.670-05:00Are passwords better than challenge questions?Based on the negative ratings I assigned some challenge questions in <a href="http://blog.passwordresearch.com/2007/07/tips-for-avoiding-bad-authentication.html">this white paper</a>, people have asked me if I believe challenge questions are worthless. No, they aren’t worthless. However, challenge questions have several inherent flaws that must be recognized and addressed for them to provide adequate authentication.<br /><br />If we were to compare a typical challenge question answer with a typical password, we would find that the password is a better authenticator. A password has both more total and likely possibilities, which improves its uniqueness. It also has better integrity than a challenge question answer because it isn’t intentionally based on personal information.<br /><br />Interestingly enough, the unstructured nature of passwords does actually present a risk that challenge questions avoid. Because asking for a password is the equivalent of asking "say anything", attackers don’t have to pay any attention to the question. A password guess of "llama" is just as acceptable as "redsox". With challenge questions, you would only expect to see "llama" as an answer to a question such as "what is your favorite animal". An answer of "redsox" for that same question doesn’t make sense and shouldn’t be guessed [1].<br /><br />If a criminal wants to penetrate online identities using a brute force password guessing attack, they only need a single list of possible usernames and passwords. They may even do their research ahead of time and limit their list to the 100 or 1,000 most popular passwords. Then the attacker unleashes their password guessing software on the web application to find valid credential combinations.<br /><br />When that same criminal wants to penetrate a challenge question authentication system using a brute force attack, they have more work to do. If the attacker uses the list of common passwords, they aren’t going to have much success, because challenge questions expect a specific type of answer. Instead, the attacker will have to come up with lists of the 100 most popular animals, 100 most popular authors, 100 most popular child names, etc. to fit the expected challenge question answers.<br /><br />Once the attacker has done this initial groundwork (or just grabbed a list from someone else) they have to configure their software to match the right list of answers with the appropriate questions. This isn’t difficult, but does put another obstacle in their path.<br /><br />Back to the original question, the real strength of challenge questions comes from the common practice of asking multiple questions to authenticate a user. An attacker can’t just run through 100 passwords and hope for a match. They have to find the right combination out of 100 animals, 100 authors, and 100 child names to penetrate a user account [2].<br /><br />Since this approach is very time consuming (100 x 100 x 100 = 1 million total guesses) an attacker is likely to shorten their lists to the top 10 most popular answers for each type of question. Or they’ll choose a different challenge question authentication attack that requires less guesswork [3].<br /><br />A single challenge question may not be better than a single password, but you don’t have to settle for that option. Address this flaw by choosing the right challenge questions and requiring users to correctly answer several of them during authentication. <br /><br /><br />1. Users don’t have to provide logical answer to challenge questions since there is no way for the system to check. Some people might purposely provide a nonsensical answer to a challenge question in an attempt to make it more password-like.<br /><br />2. Depending on the particular application’s implementation of challenge question authentication, an attacker might have to guess both this combination and the user’s password.<br /><br />3. See <a href="http://blog.passwordresearch.com/2007/07/tips-for-avoiding-bad-authentication.html">the white paper</a> for descriptions of these alternative attacks against challenge question authentication systems.Bruce K. Marshallhttp://www.blogger.com/profile/07397177700712500000noreply@blogger.com0tag:blogger.com,1999:blog-2920277117928389647.post-25978544180439157522007-07-25T15:56:00.000-05:002007-08-03T13:17:59.198-05:00T1me 0ut for Fox NewsAn IT administrator neglected to turn off directory browsing on a portion of the Fox News web site, and this was all one curious hacker needed to penetrate a server. On Monday a <a href="http://www.whitedust.net/news/3990/Fox_News" target="_blank">blog post</a> disclosed that the author had looked through files on the Fox News web server until they found a readable shell script. This script happened to contain a username and password ("T1me 0ut") used for FTP access to a server.<br /><br />After the hacker successfully used the credentials to log in, he shared the news with anyone who happened to read his blog. When the blog entry was discussed on Slashdot, his audience grew substantially and the incident gained national attention.<br /><br />Besides the obvious security oversight, Fox News may also be guilty of lying to the public. In <a href="http://www.foxnews.com/story/0,2933,290633,00.html" target="_blank">this article</a> posted by Fox News, they claim "this password, however, was long disabled." Unless the screenshots (originally appearing along with the blog entry) of FTP directory listing from their server were faked, the password was obviously still active.<br /><br />Fox News goes on to state that no "user information [...] or other personal data were ever compromised." This claim has also been <a href="http://www.whitedust.net/news/4007/Fox_News_security_hole_exposes_1.5_million_users" target="_blank">contested by hackers</a> who report they were able to download files containing names, email addresses, and telephone numbers of over 1.5 million users.<br /><br />Why Fox News would choose to make false claims about the incident is uncertain, especially if no truly sensitive personal information was disclosed. What is certain is that a few people in their organization do deserve a time out for bad behavior.Bruce K. Marshallhttp://www.blogger.com/profile/07397177700712500000noreply@blogger.com1tag:blogger.com,1999:blog-2920277117928389647.post-79669457380864023572007-07-25T14:58:00.000-05:002007-08-03T13:18:09.794-05:00Circumventing password reset systemsA hacker who goes by the alias “pdp” recently posted information about <a href="http://www.gnucitizen.org/blog/attacking-password-recovery-facilities" target="_blank">Attacking Password Recovery Facilities</a> on his blog. He reviews several approaches to gaining unauthorized access to user accounts by circumventing security in the password recovery function of a system rather than trying to guess a user’s password.<br /><br />Since attackers will often follow the path of least resistance in penetrating a host, it is incredibly important to make sure that password recovery functionality is designed to resist attacks.<br /><br />I described one of the attacks, determining the answers to a user’s challenge questions, in the white paper I mentioned in a <a href="http://blog.passwordresearch.com/2007/07/tips-for-avoiding-bad-authentication.html">past blog entry</a>. Hopefully his post will help to convince more people that attackers are going to be a real threat to their challenge question authentication systems, whether used for password recovery or secondary authentication.Bruce K. Marshallhttp://www.blogger.com/profile/07397177700712500000noreply@blogger.com0tag:blogger.com,1999:blog-2920277117928389647.post-30205786618439370362007-07-20T15:49:00.000-05:002007-08-03T13:18:21.867-05:00When is a password not a password?I recently found myself making the statement that sometimes a password isn’t a password. Maybe it is a silly semantics argument better left to high priced lawyers, but I was feeling frustrated by a particular requirement of the Payment Card Industry (PCI) <a href="https://www.pcisecuritystandards.org/pdfs/pci_dss_v1-1.pdf">Data Security Standard (DSS)</a>. This is the standard with which some organizations that process and store credit cards must comply.<br /><br />The focus of my frustration was requirement 8.4 of the PCI DSS, which says “Encrypt all passwords during transmission and storage on all system components.” I was asked whether the following scenario violated this requirement.<br /><br />An application which falls under the scope of PCI required manual approval of new user account registrations. Once the account was approved the system would email the user a temporary password. The user was required to change the password upon their first login to the application. The email containing the temporary password did not include their username or even a link to the actual application.<br /><br />On the surface this practice appears to violate the stated requirement. It doesn't violate the “at rest” part because the password isn't stored in cleartext on a system under your control. That leaves “transmission”, and I can’t deny that the application is transmitting a password. However, my belief is that the requirement did not apply in this situation. <br /><br />Without a username, a password has little value. This is like an application transmitting the last 4 digits of a credit card number (which, incidentally, the PCI standard does allow you to store unencrypted). Using this logic, I argued that this scenario shouldn't constitute transmission of a “password” because the incomplete information rendered it unusable for authentication.<br /><br />Regardless, the fact that this is only a temporary password further reduces risk. An attacker would have to read the email, determine the associated username, and find the login page all before the legitimate user first logged in. That is a pretty small window of opportunity.<br /><br />If you just want to follow the letter of the requirement, send users a URL that includes a parameter containing their password. When they follow the link, prompt for their username (and preferably another piece of personal info). If the credentials match, log them into the application and prompt for a new password. Technically you didn't send them a password because it wasn't identified as such. I really don’t consider this different from a risk standpoint. Just because the PCI standard language may discourage the first approach I don't believe you can consider the second any better.<br /><br />Whether you can convince the PCI council or a security examiner of this viewpoint is another matter.<br /><br />Ultimately, I was rebelling against the rigidity of the PCI DSS requirement, not trying to add confusion about the term “password”. I would actually prefer that the user set up their own password during account registration, but this may not be possible given the design of this particular application. However, I was satisfied that the approach taken would reduce the risk associated with emailing a temporary password to a manageable level.Bruce K. Marshallhttp://www.blogger.com/profile/07397177700712500000noreply@blogger.com0tag:blogger.com,1999:blog-2920277117928389647.post-19287405072271164542007-07-20T10:10:00.000-05:002007-08-23T10:53:57.811-05:00Tips for avoiding bad authentication challenge questionsI’m excited to share the news about a brand new white paper that I wrote for Security PS. The paper is called <a href="http://securityps.infosecmedia.com/whitepapers/TipsforAvoidingBadQuestions.pdf">Tips for Avoiding Bad Authentication Challenge Questions</a>. To be clear, a challenge question is a question used for authentication that asks you for personal information. Examples are “what is your mother’s maiden name” and “what is your pet’s name”. Financial institutions, including many of our clients, have implemented challenge questions in an effort to improve online authentication for higher risk applications.<br /><br />My goal with this paper was to review how well these questions actually succeed in effectively authenticating users. I subjected challenge questions to a <a href="http://www.passwordresearch.com/core.html">framework for evaluating authenticators</a> that I developed several years ago. I also gathered a variety of examples from clients and public sources so I could illustrate the strengths and weaknesses of different questions. I think you may be surprised by our conclusions.<br /><br />If your organization has implemented challenge question authentication or are simply interested in how much security they provide, I encourage you to give it a read. I’d love to get your feedback about the paper. Please enter your comments on this blog entry or send me an email directly. You’ll find my contact information at the end of the paper.<br /><br />Paper link: <a href="http://securityps.infosecmedia.com/whitepapers/TipsforAvoidingBadQuestions.pdf">http://securityps.infosecmedia.com/whitepapers/TipsforAvoidingBadQuestions.pdf</a>Bruce K. Marshallhttp://www.blogger.com/profile/07397177700712500000noreply@blogger.com0tag:blogger.com,1999:blog-2920277117928389647.post-845844355223902432007-07-20T10:05:00.000-05:002007-08-03T13:18:50.623-05:00Welcome to the PasswordResearch.com BlogI have enjoyed sharing password and other authentication related information with you on <a href="http://www.passwordresearch.com">PasswordResearch.com</a> the last few years. But I found it challenging to fit some news within the existing structure of the site. Organization is great until it starts inhibiting collaboration.<br /><br />Fortunately, this blog offers a less formal and structured alternative to creating new content on the main site. I am committed to posting here regularly as a supplement to the great <a href="http://www.passwordresearch.com">PasswordResearch.com</a> statistics, stories, and research. Subscribe or check back regularly here for interesting authentication updates.Bruce K. Marshallhttp://www.blogger.com/profile/07397177700712500000noreply@blogger.com0