Showing posts with label password. Show all posts
Showing posts with label password. Show all posts

2020-11-20

Suggestions For Creating Passwords

Scope And Purpose Of This Post


Even after someone makes the very wise decision to start using a password manager so they can start having strong, unique passwords, they still have to decide what password generator settings to use.  They have to decide stuff like whether to use digits and punctuation in their passwords, how long their passwords should be, and whether they should use passphrases.

The password generator settings you use should depend on how you're going to use the password.  Passphrases are great for passwords you need to remember, but maybe not for your work password that you manually type >20 times a day.  My recommendations depend on the "password use case":

  • Remembered and typed <8 times a day.
    • This would be your master password for your password manager.
    • Use a passphrase.  Six words for your master password.  Five words are okay for passwords that are far less important than your master password.
    • If your password manager doesn't generate passphrases for you, make it generate a bunch of digits and use the diceware word list or an EFF word list.
  • Not remembered and rarely/never typed.
    • Your most common password use case, for stuff like Facebook.
    • I recommend a "1D+1U+15L" password: 1 digit, 1 upper case letter, 15 lower case letters, for a total length of 17.
    • If your password generator doesn't support that, go for 14 alphanum characters (uses lower case letters, upper case letters, digits)
  • Remembered and typed many times a day.
    • This is possibly the use case for your work password, which you have to type to unlock your computer and log in to many services.
    • Because you are typing this so frequently, you might not need the memorability of a passphrase, and you probably don't want the typing hassle.
    • I recommend something like a "1D+1U+12L" password, even if you have to manually modify a password generated by your password manager.
Note: for this blog post, we'll be assuming we never use an ambiguous letter or digit ("IOlo10"), except in passphrases.  It is tempting to think that if you know that a non-passphrase password only contains lower case letters, then "l" and "o" are unambiguous, but when you're looking at the computer-generated password two years after you generated it, you won't be confident.  For passphrases, you can disambiguate based on the words ("shallow" is a word, and "shaII0w" isn't), so "l" and "o" are okay.

2020-11-13

Password Strength In Dollars

Purpose And Scope Of This Post


When discussing password strength, money-to-crack calculations are far better than time-to-crack calculations. I propose a money-to-crack model that applies to dedicated password cracking rigs as well as cloud computing, and I make some calculations using recent (2020-Nov) data.

This blog post is focused on:

  • Offline attacks (explained in Gentle Introduction)
  • Computer-generated passwords, not human-generated passwords (more info in Background: Guesses-To-Crack)

The cracking costs tables are towards the bottom, feel free to check those out first if you want to see results, not methodology and commentary.

Gentle Introduction

When someone creates a password, sometimes they are concerned about how resistant the password is to being guessed by an attacker.  For instance, a one-letter password for your bank account is probably unacceptably weak and a computer-generated 40-letter password is probably more than acceptably strong.  These two example passwords are so extreme in weakness/strength, that we can make these judgments intuitively, but we will have to be more careful and systematic if we want to determine what sorts of passwords are acceptably strong and not excessively painful to type.

This blog post will focus on password strength in the context of offline attacks, which is where an attacker has hacked some service, obtained hashes of passwords, and can very quickly check password guesses on their own machines.  Offline attacks are a worst-case scenario for password strength, and it makes sense to have the worst-case decide what we consider acceptable password strength.

There are a few ways to think about how strong a password is: guesses-to-crack (GTC, basically entropy), time-to-crack (TTC), and money-to-crack (MTC).  "Crack" simply means "correctly guess".  Each way builds on the previous way.  Discussions of password strength usually focus on GTC and TTC, and only rarely go into MTC.  I think that MTC is far superior to TTC for most discussions about passwords, and I propose my own way of calculating MTC and plug in numbers for hardware available in 2020-Nov.

Interestingly, there's only a 15x-38x difference in costs between realistic upper bounds (AWS cloud computing) and unrealistic lower bounds (arbitrary number of GPUs with no overhead).

2019-08-02

Account Recovery: Insecure And Uncertain

Summary

Account recovery procedures (ex: when someone says they lost your password and/or phone) are often the easiest way for attackers to gain access to your account, and unfortunately there is very little advice on how to deal with it, other than "turn your username, email, and security answers into unique, hard-to-guess things", in other words: make everything a password.  But account recovery procedures often make that tactic useless.

Also, I am doubtful that adding extra account recovery options (recovery phone numbers, alternate emails) is a good idea for people who are using a password manager to create and store strong, unique passwords, and have taken steps to make sure they won't lose access to their password database.  Extra account recovery options are extra ways for bad guys to get into your account and are often easier than guessing your password.

Motivation And Background

The computer security field has some things about account security pretty well settled, like use a password manager to generate and store strong, unique passwords for your accounts.  I think one of the big remaining questions is: how should users manage the risk from account recovery procedures (when someone claims to have lost your phone and/or password).

To illustrate how bad account recovery procedures from popular account providers can be, Betfair only required a username and date of birth to change someone's password, and here's the tragic story of Mat Honan from 2012:
At 4:33 p.m., according to Apple’s tech support records, someone called AppleCare claiming to be me. Apple says the caller reported that he couldn't get into his Me.com e-mail – which, of course was my Me.com e-mail.

In response, Apple issued a temporary password. It did this despite the caller’s inability to answer security questions I had set up. And it did this after the hacker supplied only two pieces of information that anyone with an internet connection and a phone can discover....It turns out, a billing address and the last four digits of a credit card number are the only two pieces of information anyone needs to get into your iCloud account.
It also used to be that to take over an Amazon account, you only had to know was a person's name and their shipping address, and to make three calls to customer service.  You could use the name and address to find out the registered email address, then use those three things to add a phony credit card number, then use those four things to change the associated email and then trigger a password reset using the new email address..

This is extremely scary.  To continue the old Amazon example, for a long time your Amazon password (and probably 2FA if they even offered it at the time) offered no protection against someone who knew your name and physical address.  I don't really know what someone could do to guard against that.

A big part of why account recovery is insecure and will probably continue to be so for a long time is incentives faced by the account providers.  The number of legitimate customers that have lost their phones and passwords outnumber bad guys on any given day.  Businesses want to please their customers and convenience-security trade-offs are being made that are probably close to what most customers want.  The average Amazon/Apple customer does NOT wanted to be locked out of their account just because they forgot their password.

2016-12-16

Password Manager Versus the Alternatives

Scope of this Post

This post will show how using a password manager compares in security and convenience to the other major ways of managing account credentials: the password manager is the winner in both categories.  This post will also cover some common objections to using password managers.

For some background, there is my previous post on account security risks.

The bottom line is:
  • The case for password managers is strong.  Security experts use and recommend them.  The biggest choice is which password manager to use, whether to use browser integration, and whether you want to use a physically secure notebook for some of your accounts.

Note: by "password manager", I mean a standalone program dedicated to managing account credentials (username, password) and stores them in encrypted form, protected by a master password.  Web browser password managers will be addressed in their own section.

Also, I'd like to recommend 2FA for all accounts you have that are of even mild value. The security benefits are large and the inconvenience is small, regardless of whether you choose to use a password manager.

Author's Note: TODO, weave in https://medium.com/@stuartschechter/before-you-use-a-password-manager-9f5949ccf168

2016-12-07

Account Security Risks and Reasons to Use a Password Manager and 2FA

Scope Of This Post and Some Basic Recommendations

I consider switching to using a password manager to be one of my best life decisions in terms of costs and benefits.  The security and convenience benefits are immense, and the costs (setup effort) are small.  Yes, using a password manager made managing and logging in to my accounts much easier, faster, and less stressful, but this post will focus on security issues.  My thanks to Troy Hunt for influencing me to make the plunge.

Without a password manager, it borders on impossible for a human to do passwords correctly.  By "do passwords correctly", I mean having strong, unique passwords for all of your accounts.  To illustrate why it is good to have strong, unique passwords, I will go over several of the account security risks most humans face, with special emphasis on passwords.  Maybe this will directly persuade some people to start using a password manager, but also it will establish some background for another post that will discuss why password managers are big security improvement over the alternatives and are overall the best choice.

For generating strong passwords (with the goal of surviving offline attacks), I recommend:
  • For passwords you want to remember, such as your Google password and master password: choose 6 random words from the Diceware word list (pdf).
  • For passwords managed by your password manager (you don't have to remember them and it's very rare to actually type them): have your password manager randomly generate at least 16 random lower case letters, upper case letters, and digits.

Also, I highly recommend enabling 2FA on all of your accounts of even mild worth.  A very common form of 2FA is that when logging in from an unrecognized device, the login attempt will also require a verification code sent to the account's associated email or phone.  This additional layer of defense may protect you even when bad people know your password, and 2FA is only a minor and rare inconvenience.

2016-12-04

Steps to Set Up KeePass

Scope of this Post

The following instructions are for how to set up the KeePass password manager on your Windows PCs, iPhones, and Android devices.  This post also covers the one-time process of creating a password database and putting it in Google Drive.

If you are hoping to use KeePass on Linux or MacOS, I haven't done it myself, but you might have success using KeePassXC or one of the KeePass packages that has made it into Mac OS X and several Linux distribution software repositories.  See this page for download options.  Also, there's the option of running KeePass under Mono on your MacOSX/Linux system.

If you use the following steps, you'll be able to access your always-up-to-date password database from all of your devices that you've installed KeePass on.

This post assumes you are comfortable using KeePass Plugins and also browser plugins which make using KeePass extremely convenient.  Future posts will cover if you want to be paranoid and trust only KeePass itself and Google.

The most notable links, folder locations, and component names are bolded.

Note that the version of KeePass we'll be using is KeePass2, so don't be afraid when folders or apps talk about KeePass2.