Skip to content

Dustin D. Trammell

Venture Capitalist, InfoSec Research Scientist, Entrepreneur, Artist, Game Designer

Written by I)ruidSeptember 18, 2008October 8, 2020

(In)Security Questions

A number of years ago, as the Internet became more and more mainstream, websites and web services began to push to the forefront of online business and society.  This generally required allowing users to create accounts with these increasingly complex sites and services, and thus, the entities providing them had to then manage those accounts.  In these early days, such user accounts began to be compromised due to their easily guessable or brute-forceable passwords, so nowadays most sites require users to use relatively complex passwords.  Humans are simply not good at remembering such things, and customer service expenses soon skyrocketed under the flood of users constantly requesting password resets to regain access to their accounts.  The business solution to this?  Let the users reset the passwords themselves!

Sounds like a great idea, right?  Unfortunately the most widely adopted scheme to allow users to do this is to ask the user a number of easy to remember “security” questions, which the user must provide the correct answer(s) to in order to initiate a password reset.  If the user answered the question(s) correctly, they are then allowed to choose a new password for the account.  It just so happens that in most cases, easy to remember questions like which are commonly used for these mechanisms are also easily guessable, or easily researched.  I briefly touched on this topic in my Mnemonic Password Formulas paper.  As we recently saw with Republican Vice Presidential nominee Sara Palin’s email being “hacked”, among countless other similar incidents, this is a fairly significant and prevalent problem.

Essentially, what Yahoo Mail’s and other similar password reset mechanisms boil down to is a significant reduction of the security of the account from the security of a complex password authentication to the security of an easy to answer question or two.  If you stop to consider this, it’s fairly obvious what an attacker who wanted to gain access to your account would do.  What’s the easiest attack vector given those two options?  Obviously, the easy to answer question.

Now, a password reset mechanism is not necessarily an inherently bad thing.  As mentioned before, it can drastically cut an operation’s customer support costs.  But how can this type of mechanism be made more secure?

First, the reset mechanism should never be entirely reliant upon just the “security” questions.  One or more of these questions is fine to initiate the process, but they should not be the entire process.  If the web site or service in question allows you to actively reset the account password right there through the web interface after answering the question(s), this is bad.  Very, very bad.  A better way to do this is to have the reset mechanism generate a temporary password for the account, and then provide that to the user.

Second, the reset mechanism should utilize some previously verified communications channel other than the web interface that the password reset was requested from.  For most websites or services, a verified email address would suffice.  By sending a temporary password to the user’s validated email address rather than allowing them to actively change it, this requires an attacker to also have previously compromised the user’s email account, or at least be able to observe the email traffic.  Now obviously this poses a problem if the web service in question is the user’s email service.  So how about sending it to the user’s cellular phone via SMS?  The user’s IM account?  In drastic circumstances, the temporary password could be sent to the user’s home address via postal mail.

Now obviously many of these communications channels are less than secure, but at least you have a reasonable expectation that the intended recipient will recieve the information.  But what happens if an attacker can observe the information as it traverses one of these communications channels?  One method to limit this type of exposure is to send part of the password over one channel, and the other part over another.  This splits the temporary password into multiple pieces, adding additional challenge to the attacker who must now be observing all of the potential ways that the temporary password, or various parts of it, could be sent to the user.  If you’ve noticed, in this section I’ve been explicitly referring to the password sent as a temporary password.  Setting a new password upon regaining access to the account should always be required, in case the password sent falls victim to the threat discussed here and was somehow observed in transit.

Third, authentication systems should ideally require some form of two-factor authentication.  Note, this does not mean two different passwords, such as a password and a PIN number, as many in the financial industry seem to think it means.  No, this means two different kinds of authentication credentials, such as something the user knows, like a password, and something the user has, like a crypto-token generated from a smartcard.  When dealing with multi-factor authentication systems, whether or not one of the factors such as the password becomes compromised is relatively moot, as an attacker cannot authenticate using only that piece of information.

What can you do as a user to help mitigate these issues if the system you’re using uses “security questions” for their password reset mechanism?  Just lie.  Sometimes (very rarely) it’s OK to lie, and this is one of them.  Make up some nonsensical answer to each question that no one would ever be able to guess or research, and store those answers in your password manager along with your password.  You do use a password manager, right?  If for some reason your password stops working and needs to be reset, because obviously YOU won’t lose it, being in your password manager, then you have the security question answers saved as well for your account recovery.

Share this:

  • Twitter
  • Facebook
  • LinkedIn
  • Tumblr
  • Reddit

Like this:

Like Loading...

Related

Posted in account security, hack, passwords, security.

Leave a Reply Cancel reply

Recent Posts

  • The History of Bitcoin’s Copyright
  • Block 286 and Satoshi’s Coins
  • Faketoshi Craig Wright Lies Exposed
  • 2nd Amendment, Modernized
  • Twitter Cryptoasset Trading Bot (TCTBot)

Recent Comments

Dustin D. Trammell on I Am Not Satoshi
Correos intercambiad… on Nakamoto Family Foundation
Les premiers mineurs… on I Am Not Satoshi
Les premiers mineurs… on The Problem With the Liberty D…
Les premiers mineurs… on The Problem With the Liberty D…

Archives

  • January 2023
  • September 2022
  • May 2021
  • June 2020
  • April 2020
  • March 2020
  • December 2018
  • July 2018
  • July 2017
  • June 2017
  • September 2015
  • November 2013
  • June 2012
  • April 2012
  • February 2012
  • March 2011
  • November 2010
  • October 2010
  • July 2010
  • April 2010
  • March 2010
  • December 2009
  • November 2009
  • August 2009
  • February 2009
  • January 2009
  • December 2008
  • November 2008
  • September 2008
  • August 2008
  • July 2008
  • June 2008
  • April 2008
  • February 2008
  • January 2008
  • November 2007
  • October 2007
  • September 2007
  • August 2007
  • May 2007
  • April 2007
  • March 2007
  • February 2007
  • January 2007
  • October 2006
  • September 2006
  • March 2006
  • September 2005
  • August 2005

Categories

  • account security
  • administrivia
  • advisory
  • AHA!
  • attack
  • authentication
  • biometrics
  • Bitcoin
  • bodyhacking
  • Book Review
  • Books
  • business
  • CAU
  • Civics
  • conference
  • Cryptoasset
  • Cryptocurrency
  • cryptography
  • device security
  • economics
  • education
  • employment
  • endpoint security
  • exploit
  • family
  • finance
  • food
  • Game Development
  • gaming
  • Government
  • hack
  • hardware
  • hpavc
  • humor
  • infrastructure security
  • ketogenic diet
  • locks
  • nintendo
  • observation
  • opinion
  • passwords
  • patch management
  • perimeter security
  • Personal
  • physical security
  • Politics
  • rant
  • reverse engineering
  • review
  • security
  • security research
  • software
  • stats
  • steganography
  • technology
  • telephony
  • testing
  • threat modeling
  • Trading
  • travel
  • Uncategorized
  • video games
  • voip
  • vulnerability
  • whitepaper
  • wii

Meta

  • Log in
  • Entries feed
  • Comments feed
  • WordPress.org

Recent Posts

  • The History of Bitcoin’s Copyright
  • Block 286 and Satoshi’s Coins
  • Faketoshi Craig Wright Lies Exposed
  • 2nd Amendment, Modernized
  • Twitter Cryptoasset Trading Bot (TCTBot)

Recent Comments

Dustin D. Trammell on I Am Not Satoshi
Correos intercambiad… on Nakamoto Family Foundation
Les premiers mineurs… on I Am Not Satoshi
Les premiers mineurs… on The Problem With the Liberty D…
Les premiers mineurs… on The Problem With the Liberty D…

Archives

  • January 2023
  • September 2022
  • May 2021
  • June 2020
  • April 2020
  • March 2020
  • December 2018
  • July 2018
  • July 2017
  • June 2017
  • September 2015
  • November 2013
  • June 2012
  • April 2012
  • February 2012
  • March 2011
  • November 2010
  • October 2010
  • July 2010
  • April 2010
  • March 2010
  • December 2009
  • November 2009
  • August 2009
  • February 2009
  • January 2009
  • December 2008
  • November 2008
  • September 2008
  • August 2008
  • July 2008
  • June 2008
  • April 2008
  • February 2008
  • January 2008
  • November 2007
  • October 2007
  • September 2007
  • August 2007
  • May 2007
  • April 2007
  • March 2007
  • February 2007
  • January 2007
  • October 2006
  • September 2006
  • March 2006
  • September 2005
  • August 2005

Categories

  • account security
  • administrivia
  • advisory
  • AHA!
  • attack
  • authentication
  • biometrics
  • Bitcoin
  • bodyhacking
  • Book Review
  • Books
  • business
  • CAU
  • Civics
  • conference
  • Cryptoasset
  • Cryptocurrency
  • cryptography
  • device security
  • economics
  • education
  • employment
  • endpoint security
  • exploit
  • family
  • finance
  • food
  • Game Development
  • gaming
  • Government
  • hack
  • hardware
  • hpavc
  • humor
  • infrastructure security
  • ketogenic diet
  • locks
  • nintendo
  • observation
  • opinion
  • passwords
  • patch management
  • perimeter security
  • Personal
  • physical security
  • Politics
  • rant
  • reverse engineering
  • review
  • security
  • security research
  • software
  • stats
  • steganography
  • technology
  • telephony
  • testing
  • threat modeling
  • Trading
  • travel
  • Uncategorized
  • video games
  • voip
  • vulnerability
  • whitepaper
  • wii

Meta

  • Log in
  • Entries feed
  • Comments feed
  • WordPress.org

Post navigation

Previous Post Penetration Test != Audit != Assessment
Next Post What, no ToorCon???
Powered by WordPress.com.
%d bloggers like this: