Implementing password resets is hard. The problem comes down to how we authenticate a user who forgot the common secret(s) we shared. We all know, that password reset questions are often just weak password bypassquestions, and can not be used to authenticate a user reliably.

[OK OK OK... I see the comments already: But I dont answer them correctly. Sure: you do. but you are also reading a blog about password reset questions. ...]

Lets talk about resetting passwords. In my opinion, password reset questions should never be considered as an authentication mechanism. Lets call them a rate-limiting tool: They prevent an attacker from flooding a victim with password reset e-mails. But this is about all they are good for.

So what else can we do? SMS or automated phone calls can be a reasonable option for some sites, but NIST in recent guidance regarding two-factor authentication pointed out that it is certainly possible for an attacker to obtain access to someones SMS traffic. To do so, an attacker has to convince a phone company to add a new phone to the account. The process usually involves answering some questions similar to password reset questions, or some social engineering. The phone/SMS authentication isnt any better than theweak password reset questions we try to get rid off.

There is another method I have seen implemented a coupleof times. I call it password buddy. When you set up an account, you select a few individuals that may approve password resets on your behalf. In a corporate environment, these may be coworkers or your boss. But it could also be a family member. For this to work, both parties need to have an account at the same site.

Here is a quick workflow how this works:

  1. User starts the password reset process
  2. The user will answer a password reset question (quality of the question isnt all that important in that case)
  3. Answering the question will trigger an email or SMS to the user with a one-time code. The purpose of the code is to prevent a DoS attack where someone starts the password reset but doesnt complete it, in effect locking out the user.
  4. The user uses the one-time password select a new password. At this point, the account is locked
  5. The user now notifies the password buddy and asks them to approve the reset
  6. The password buddy logs in and will be presented with an option to approve the password reset
  7. This will unlock the account. The user can now log in using the new password. (maybe send an e-mail to the user to notify them)

So this is the rough outline of the process. There are some possible problems with it:

  • A password buddy may use their access to reset your password. This is why we still send an e-mail to the account holder, and we still ask password reset questions. At least we are not worse off than before.
  • Same as above, but instead of your buddy turning against you, an attacker is taking over the buddys account.
  • An attacker could social engineer your buddy into approving the password reset. To do so, the attacker needs to know who the person is. It should also be more difficult to impersonate you to a person you know very well as compared to some anonymous help desk.
  • What if your password buddies aren">This is why you pick a couple. Lets hope one of them is available in time.

If there is something else that doesnt work in security, then it is central anonymous help desks. They can almost always be social engineered. The idea behind this system is that you authenticate to someone who you work with daily, maybe you can even just walk over to them and ask them for help in person. Or a family member that knows you very well.

The buddy will never see your password. They just approve the fact that you changed it. They will also not know your password reset questions and any other details about your account. How they authenticate you is up to them, but in a corporate environment, you may want to set up some rules around how the authentication should happen (in person, over the phone...)

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
 
FortiWLC CVE-2016-7560 Hardcoded Account Security Bypass Vulnerability
 
FreeImage CVE-2016-5684 Remote Code Execution Vulnerability
 
Redis CVE-2016-8339 Out of Bounds Remote Code Execution Vulnerability
 
Cybozu Office Multiple Cross Site Scripting Vulnerabilities
 
[SECURITY] [DSA 3684-1] libdbd-mysql-perl security update
 
Pivotal Spring Data JPA CVE-2016-6652 SQL Injection Vulnerability
 
Google Chrome Prior to 52.0.2743.82 Multiple Security Vulnerabilities
 
SAP Security Audit Log CVE-2016-4551 Security Bypass Vulnerability
 

A major battle is underway for control over hundreds of millions of network-connected digital video recorders, cameras, and other so-called Internet of Things devices. As Ars has chronicled over the past two weeks, hackers are corralling them into networks that are menacing the security news site KrebsOnSecurity and other Web destinations with some of the biggest distributed denial-of-service attacks ever recorded.

Johannes B. Ullrich, a researcher and chief technology officer for the SANS Internet Storm Center, wanted to know just how vulnerable these devices are to remote takeover, so he connected an older DVR to a cable modem Internet connection. What he saw next—a barrage of telnet connection attempts so dizzying it crashed his device—was depressing.

"The sad part is, that I didn't have to wait long," he wrote in a blog post published Monday. "The IP address is hit by telnet attempts pretty much every minute. Instead of having to wait for a long time to see an attack, my problem was that the DVR was often overwhelmed by the attacks, and the telnet server stopped responding. I had to reboot it every few minutes."

Read 4 remaining paragraphs | Comments

 
PostgreSQL CVE-2016-5423 NULL Pointer Dereference Remote Code Execution Vulnerability
 
Opensuse CVE-2014-9601 Denial-Of-Service Vulnerability
 
IBM B2B Advanced Communications CVE-2016-5892 Cross Site Scripting Vulnerability
 

Enlarge / EMC Unisphere apparently had holes as big as the ones in the Unisphere at Flushing Meadows.

Digital Defense announced today that it privately revealed a set of five zero-day vulnerabilities in Dell EMC's vApp Manager for Unisphere for VMAX, a Web application used to manage all of EMC's storage platforms. The flaws would allow an attacker with access to the network storage devices to send malicious Adobe Flash Action Message Format (AMF) messages to the Web application server running on the storage system. That means attackers could run arbitrary commands against the storage system and potentially gain complete control of the storage devices or shut them down. The flaws have been patched by EMC via security advisories on the vulnerabilities available only to Dell EMC customers.

Weaknesses were found in how Unisphere for VMAX, which usually runs on a "virtual appliance" on a VMware server, used the AMF protocol to send messages to five different interfaces on the Unisphere Web application server, sometimes without requiring authentication. The worst of these is a vulnerability that allows "arbitrary command execution with root privileges, complete compromise of the virtual appliance," Digital Defense reported in a post on the vulnerabilities. That includes the capability of creating new user credentials to give attackers unfettered access.

Over 3,300 companies worldwide use Symmetrix VMAX to manage storage systems, including T-Mobile and a number of major financial institutions. While attacks would have likely required access to the data center LANs that the systems run on, that sort of access isn't out of the question. Attackers that managed to exploit a connected Web server or other system in the data center would be able to take advantage. In a worst-case scenario, an attacker could both steal large amounts of corporate data and bring storage systems offline.

Read on Ars Technica | Comments

 
Pacemaker CVE-2016-7797 Remote Denial of Service Vulnerability
 
Ruby OpenSSL Security Bypass Vulnerability
 
Google Chrome OS Security Bypass and Arbitrary Code Execution Vulnerabilities
 
Apache Tomcat CVE-2016-1240 Local Privilege Escalation Vulnerability
 
C-ares CVE-2016-5180 Out of Bounds Write Denial of Service Vulnerability
 
CVE-2016-1240 - Tomcat packaging on Debian-based distros - Local Root Privilege Escalation
 
[SECURITY] [DSA 3681-2] wordpress regression update
 
Internet Storm Center Infocon Status