Attacks/Breaches
5/7/2013
11:04 AM
Connect Directly
RSS
E-Mail
50%
50%
Repost This

Sweet Password Security Strategy: Honeywords

To improve detection of database breaches, businesses should store multiple fake passwords and monitor attempts to use them, according to researchers at security firm RSA.

10 Top Password Managers
10 Top Password Managers
(click image for slideshow)
Businesses should seed their password databases with fake passwords and then monitor all login attempts for use of those credentials to detect if hackers have stolen stored user information.

That's the thinking behind the "honeywords" concept first proposed this month in "Honeywords: Making Password-Cracking Detectable," a paper written by Ari Juels, chief scientist at security firm RSA, and MIT professor Ronald L. Rivest, who co-invented the RSA algorithm (he's the "R").

The term "honeywords" is a play on "honeypot," which in the information security realm refers to creating fake servers and then learning how attackers attempt to exploit them -- in effect, using them to help detect more widespread intrusions inside a network.

"[Honeywords are] a simple but clever idea," said Bruce Schneier, chief security technology officer of BT, in a blog post. "Seed password files with dummy entries that will trigger an alarm when used. That way a site can know when a hacker is trying to decrypt the password file."

The honeywords concept is also elegant because any attacker who's able to steal a copy of a password database won't know if the information it contains is real or fake. "An adversary who steals a file of hashed passwords and inverts the hash function cannot tell if he has found the password or a honeyword," Juels and Rivest pointed out. "The attempted use of a honeyword for login sets off an alarm. An auxiliary server (the "honeychecker") can distinguish the user password from honeywords for the login routine and will set off an alarm if a honeyword is submitted."

[ Two-factor authentication is a good first step, but it's not enough. Here's why. Twitter Two-Factor Authentication: Too Little, Too Late? ]

The researchers recommend honeywords as a step beyond creating fake accounts. "Sometimes administrators set up fake user accounts ("honeypot accounts") so that an alarm can be raised when an adversary who has solved for a password for such an account by inverting a hash from a stolen password file then attempts to login," they said. "Since there is really no such legitimate user, the adversary's attempt is reliably detected when this occurs." But they said that attackers may find viable techniques for spotting bogus accounts.

Accordingly, they recommend adding multiple fake passwords to every user account and creating a system that allows only the valid password to work and that alerts administrators whenever someone attempts to use a honeyword. "This approach is not terribly deep, but it should be quite effective, as it puts the adversary at risk of being detected with every attempted login using a password obtained by brute-force solving a hashed password," they said.

If honeyword use is detected, that doesn't mean that the password database has been compromised. Instead, attackers may simply be launching brute-force-guessing attacks against the site. On the other hand, if numerous attempted logins are made using honeywords, or if honeyword login attempts are made to admin accounts, then it's more likely that the password database has been stolen.

One benefit of the RSA researchers' approach is that businesses could improve their security posture without any user intervention. "Honeywords aren't visible to users and don't in any way change their experience when they log in using passwords," read a related FAQ.

The researchers acknowledge that attackers might subvert their system by launching a denial-of-service attack against a honeychecker server. In such an event, they recommend using a failsafe: if a honeychecker server becomes unavailable, temporarily allow honeywords to become valid logins.

Honeywords aren't meant to serve as a replacement for good password security practices. But as numerous breaches continue to demonstrate, regardless of the security that businesses have put in place, they often fail to detect when users' passwords have been compromised. Last month, for example, LivingSocial said that attackers stole information relating to 50 million users, and stolen passwords were reportedly published in underground forums. Two state attorneys general are now investigating. In March, meanwhile, Evernote reset all 50 million users' passwords after the company's security team discovered and blocked suspicious activity on the Evernote network.

Those are hardly isolated incidents. In the space of a single week last year, 6.5 million LinkedIn, 1.5 million eHarmony and an estimated 17 million Last.fm users' password hashes were uploaded to hacking forums. Although security experts suspect the passwords may have been stolen as early as 2011 or 2010, the affected businesses appeared to learn about the breaches only after the hashes were posted.

Many businesses -- including Evernote -- used encryption algorithms to protect passwords, sometimes also with salt for added protection. But that approach is insecure, and password-security experts have long recommended that businesses use built-for-purpose password hashing algorithms such as bcrypt, scrypt or PBKDF2, which if properly implemented are much more resistant to brute-force attacks.

Regardless, no password security system is foolproof. That's why an early warning system such as the use of honeywords might buy breached businesses valuable time to expire passwords after a successful attack, before attackers have time to put the stolen information to use.

People are your most vulnerable endpoint. Make sure your security strategy addresses that fact. Also in the new, all-digital How Hackers Fool Your Employees issue of Dark Reading: Effective security doesn't mean stopping all attackers. (Free registration required.)

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2012-3946
Published: 2014-04-24
Cisco IOS before 15.3(2)S allows remote attackers to bypass interface ACL restrictions in opportunistic circumstances by sending IPv6 packets in an unspecified scenario in which expected packet drops do not occur for "a small percentage" of the packets, aka Bug ID CSCty73682.

CVE-2012-5723
Published: 2014-04-24
Cisco ASR 1000 devices with software before 3.8S, when BDI routing is enabled, allow remote attackers to cause a denial of service (device reload) via crafted (1) broadcast or (2) multicast ICMP packets with fragmentation, aka Bug ID CSCub55948.

CVE-2013-6738
Published: 2014-04-24
Cross-site scripting (XSS) vulnerability in IBM SmartCloud Analytics Log Analysis 1.1 and 1.2 before 1.2.0.0-CSI-SCALA-IF0003 allows remote attackers to inject arbitrary web script or HTML via an invalid query parameter in a response from an OAuth authorization endpoint.

CVE-2014-0188
Published: 2014-04-24
The openshift-origin-broker in Red Hat OpenShift Enterprise 2.0.5, 1.2.7, and earlier does not properly handle authentication requests from the remote-user auth plugin, which allows remote attackers to bypass authentication and impersonate arbitrary users via the X-Remote-User header in a request to...

CVE-2014-2391
Published: 2014-04-24
The password recovery service in Open-Xchange AppSuite before 7.2.2-rev20, 7.4.1 before 7.4.1-rev11, and 7.4.2 before 7.4.2-rev13 makes an improper decision about the sensitivity of a string representing a previously used but currently invalid password, which allows remote attackers to obtain potent...

Best of the Web