Schneier on Security: Tagged passwords

Entries Tagged "passwords"

Page 26 of 27

Password Safe

Password Safe is a free Windows password-storage utility. These days, anyone who is on the Web regularly needs too many passwords, and it’s impossible to remember them all. I have long advocated writing them all down on a piece of paper and putting it in your wallet.

I designed Password Safe as another solution. It’s a small program that encrypts all of your passwords using one passphrase. The program is easy to use, and isn’t bogged down by lots of unnecessary features. Security through simplicity.

Password Safe 2.11 is now available.

Currently, Password Safe is an open source project at SourceForge, and is run by Rony Shapiro. Thank you to him and to all the other programmers who worked on the project.

Note that my Password Safe is not the same as this, this, this, or this PasswordSafe. (I should have picked a more obscure name for the program.)

It is the same as this, for the PocketPC.

Posted on June 15, 2005 at 1:35 PM • View Comments

Picking Physicists' Locks

From Scientific American:

Measured to be equal to 1/137.03599976, or approximately 1/137, [the fine-structure constant] has endowed the number 137 with a legendary status among physicists (it usually opens the combination locks on their briefcases).

So now you know, too.

Posted on June 15, 2005 at 8:10 AM • View Comments

Phishing and Identity Theft

I’ve already written about identity theft, and have said that the real problem is fraudulent transactions. This essay says much the same thing:

So, say your bank uses a username and password to login to your account. Conventional wisdom (?) says that you need to prevent the bad guys from stealing your username and password, right? WRONG! What you are trying to prevent is the bad guys STEALING YOUR MONEY. This distinction is very important. If you have an account with $0 dollars in it, which you never use, what does it matter if someone knows the access details? Your username and password are only valuable insofar as the bank allows anyone who knows them to take your money. And therein lies the REAL problem. The bank is too lazy (or incompetent) to do what Bruce Schneier describes as “authenticate the transaction, not the person”. While it is incredibly difficult to prevent the bad guys from stealing access credentials (especially with browsers like Internet Explorer around), it is actually much simpler to prevent your money disappearing off to some foreign country….

When something goes wrong, the bank will tell you that you “authorised” the transaction, where in fact the party who ultimately “authorised” it is the bank, based on the information they chose to take as evidence that this transaction is the genuine desire of a legitimate customer.

The essay provides some recommendations as well.

Restrict IP addresses outside Australia
Restrict odd times of day (or at least be more vigilant)
Set cookies to identify machines
Record IP usually used
Record times of day usually accessed
Record days of week/month
Send emails when suspicious activity is detected
Lock accounts when fraud is suspected
Introduce a delay in transfers out—for suspicious amounts, longer
Make care proportional to risk
Define risk relative to customer, not bank

These are good ideas, but need more refinement in the specifics. But they’re a great start, and banks would do well to pay attention to them.

Posted on May 10, 2005 at 4:24 PM • View Comments

Blowfish on "24"

Two nights ago, my encryption algorithm Blowfish was mentioned on the Fox show “24.” An alleged computer expert from the fictional anti-terror agency CTU was trying to retrieve some files from a terrorist’s laptop. This is the exchange between the agent and the terrorist’s girlfriend:

They used Blowfish algorithm.

How can you tell?

By the tab on the file headers.

Can you decrypt it?

CTU has a proprietary algorithm. It shouldn’t take that long. We’ll start by trying to hack the password. Let’s start with the basics. Write down nicknames, birthdays, pets—anything you think he might have used.

Posted on April 27, 2005 at 12:26 PM • View Comments

Passwords Alone Don't Protect Trade Secrets

A court ruled that simply password-protecting a file isn’t enough to make it a trade secret.

To establish that information is a trade secret under the ITSA, two requirements must be met: (1) the plaintiff must show the information was sufficiently secret to give the plaintiff a competitive advantage, and (2) the plaintiff must show that it took affirmative measures to prevent others from acquiring or using the information. Although the court determined in this case that the customer lists met the first requirement, it denied trade secret protection based on the second requirement.

The court held that “[r]estricting access to sensitive information by assigning employees passwords on a need-to-know basis is a step in the right direction.” This precaution in and of itself, however was not enough. The court was “troubled by the failure to either require employees to sign confidentiality agreements, advise employees that its records were confidential, or label the information as confidential.” There was insufficient evidence in the record to show the employees understood the information to be confidential, thus the trial court’s finding that the customer lists were not trade secrets was not against the manifest weight of the evidence.

Posted on April 14, 2005 at 1:05 PM • View Comments

The Failure of Two-Factor Authentication

Two-factor authentication isn’t our savior. It won’t defend against phishing. It’s not going to prevent identity theft. It’s not going to secure online accounts from fraudulent transactions. It solves the security problems we had ten years ago, not the security problems we have today.

The problem with passwords is that they’re too easy to lose control of. People give them to other people. People write them down, and other people read them. People send them in e-mail, and that e-mail is intercepted. People use them to log into remote servers, and their communications are eavesdropped on. They’re also easy to guess. And once any of that happens, the password no longer works as an authentication token because you can’t be sure who is typing that password in.

Two-factor authentication mitigates this problem. If your password includes a number that changes every minute, or a unique reply to a random challenge, then it’s harder for someone else to intercept. You can’t write down the ever-changing part. An intercepted password won’t be good the next time it’s needed. And a two-factor password is harder to guess. Sure, someone can always give his password and token to his secretary, but no solution is foolproof.

These tokens have been around for at least two decades, but it’s only recently that they have gotten mass-market attention. AOL is rolling them out. Some banks are issuing them to customers, and even more are talking about doing it. It seems that corporations are finally waking up to the fact that passwords don’t provide adequate security, and are hoping that two-factor authentication will fix their problems.

Unfortunately, the nature of attacks has changed over those two decades. Back then, the threats were all passive: eavesdropping and offline password guessing. Today, the threats are more active: phishing and Trojan horses.

Here are two new active attacks we’re starting to see:

Man-in-the-Middle attack. An attacker puts up a fake bank website and entices user to that website. User types in his password, and the attacker in turn uses it to access the bank’s real website. Done right, the user will never realize that he isn’t at the bank’s website. Then the attacker either disconnects the user and makes any fraudulent transactions he wants, or passes along the user’s banking transactions while making his own transactions at the same time.
Trojan attack. Attacker gets Trojan installed on user’s computer. When user logs into his bank’s website, the attacker piggybacks on that session via the Trojan to make any fraudulent transaction he wants.

See how two-factor authentication doesn’t solve anything? In the first case, the attacker can pass the ever-changing part of the password to the bank along with the never-changing part. And in the second case, the attacker is relying on the user to log in.

The real threat is fraud due to impersonation, and the tactics of impersonation will change in response to the defenses. Two-factor authentication will force criminals to modify their tactics, that’s all.

Recently I’ve seen examples of two-factor authentication using two different communications paths: call it “two-channel authentication.” One bank sends a challenge to the user’s cell phone via SMS and expects a reply via SMS. If you assume that all your customers have cell phones, then this results in a two-factor authentication process without extra hardware. And even better, the second authentication piece goes over a different communications channel than the first; eavesdropping is much, much harder.

But in this new world of active attacks, no one cares. An attacker using a man-in-the-middle attack is happy to have the user deal with the SMS portion of the log-in, since he can’t do it himself. And a Trojan attacker doesn’t care, because he’s relying on the user to log in anyway.

Two-factor authentication is not useless. It works for local login, and it works within some corporate networks. But it won’t work for remote authentication over the Internet. I predict that banks and other financial institutions will spend millions outfitting their users with two-factor authentication tokens. Early adopters of this technology may very well experience a significant drop in fraud for a while as attackers move to easier targets, but in the end there will be a negligible drop in the amount of fraud and identity theft.

This essay will appear in the April issue of Communications of the ACM.

Posted on March 15, 2005 at 7:54 AM • View Comments

Speech-Activated Password Resets

This is a clever idea from Microsoft.

We know that people forget their passwords all the time, and I’ve already written about how secret questions as a backup password are a bad idea. Here’s a system where a voiceprint acts as a backup password. It’s a biometric password, which makes it good. Presumably the system prompts the user as to what to say, so the user can’t forget his voice password. And it’s hard to hack. (Yes, it’s possible to hack. But so is the password.)

But the real beauty of this system is that it doesn’t require a customer support person to deal with the user. I’ve seen statistics showing that 25% of all help desk calls are by people who forget their password, they cost something like $20 a call, and they take an average of 10 minutes. A system like this provides good security and saves money.

Posted on March 11, 2005 at 1:22 PM • View Comments

The Curse of the Secret Question

It’s happened to all of us: We sign up for some online account, choose a difficult-to-remember and hard-to-guess password, and are then presented with a “secret question” to answer. Twenty years ago, there was just one secret question: “What’s your mother’s maiden name?” Today, there are more: “What street did you grow up on?” “What’s the name of your first pet?” “What’s your favorite color?” And so on.

The point of all these questions is the same: a backup password. If you forget your password, the secret question can verify your identity so you can choose another password or have the site e-mail your current password to you. It’s a great idea from a customer service perspective—a user is less likely to forget his first pet’s name than some random password—but terrible for security. The answer to the secret question is much easier to guess than a good password, and the information is much more public. (I’ll bet the name of my family’s first pet is in some database somewhere.) And even worse, everybody seems to use the same series of secret questions.

The result is the normal security protocol (passwords) falls back to a much less secure protocol (secret questions). And the security of the entire system suffers.

What can one do? My usual technique is to type a completely random answer—I madly slap at my keyboard for a few seconds—and then forget about it. This ensures that some attacker can’t bypass my password and try to guess the answer to my secret question, but is pretty unpleasant if I forget my password. The one time this happened to me, I had to call the company to get my password and question reset. (Honestly, I don’t remember how I authenticated myself to the customer service rep at the other end of the phone line.)

Which is maybe what should have happened in the first place. I like to think that if I forget my password, it should be really hard to gain access to my account. I want it to be so hard that an attacker can’t possibly do it. I know this is a customer service issue, but it’s a security issue too. And if the password is controlling access to something important—like my bank account—then the bypass mechanism should be harder, not easier.

Passwords have reached the end of their useful life. Today, they only work for low-security applications. The secret question is just one manifestation of that fact.

This essay originally appeared on Computerworld.

Posted on February 11, 2005 at 8:00 AM • View Comments

Authentication and Expiration

There’s a security problem with many Internet authentication systems that’s never talked about: there’s no way to terminate the authentication.

A couple of months ago, I bought something from an e-commerce site. At the checkout page, I wasn’t able to just type in my credit-card number and make my purchase. Instead, I had to choose a username and password. Usually I don’t like doing that, but in this case I wanted to be able to access my account at a later date. In fact, the password was useful because I needed to return an item I purchased.

Months have passed, and I no longer want an ongoing relationship with the e-commerce site. I don’t want a username and password. I don’t want them to have my credit-card number on file. I’ve received my purchase, I’m happy, and I’m done. But because that username and password have no expiration date associated with them, they never end. It’s not a subscription service, so there’s no mechanism to sever the relationship. I will have access to that e-commerce site for as long as it remembers that username and password.

In other words, I am liable for that account forever.

Traditionally, passwords have indicated an ongoing relationship between a user and some computer service. Sometimes it’s a company employee and the company’s servers. Sometimes it’s an account and an ISP. In both cases, both parties want to continue the relationship, so expiring a password and then forcing the user to choose another is a matter of security.

In cases with this ongoing relationship, the security consideration is damage minimization. Nobody wants some bad guy to learn the password, and everyone wants to minimize the amount of damage he can do if he does. Regularly changing your password is a solution to that problem.

This approach works because both sides want it to; they both want to keep the authentication system working correctly, and minimize attacks.

In the case of the e-commerce site, the interests are much more one-sided. The e-commerce site wants me to live in their database forever. They want to market to me, and entice me to come back. They want to sell my information. (This is the kind of information that might be buried in the privacy policy or terms of service, but no one reads those because they’re unreadable. And all bets are off if the company changes hands.)

There’s nothing I can do about this, but a username and password that never expire is another matter entirely. The e-commerce site wants me to establish an account because it increases the chances that I’ll use them again. But I want a way to terminate the business relationship, a way to say: “I am no longer taking responsibility for items purchased using that username and password.”

Near as I can tell, the username and password I typed into that e-commerce site puts my credit card at risk until it expires. If the e-commerce site uses a system that debits amounts from my checking account whenever I place an order, I could be at risk forever. (The US has legal liability limits, but they’re not that useful. According to Regulation E, the electronic transfers regulation, a fraudulent transaction must be reported within two days to cap liability at US$50; within 60 days, it’s capped at $500. Beyond that, you’re out of luck.)

This is wrong. Every e-commerce site should have a way to purchase items without establishing a username and password. I like sites that allow me to make a purchase as a “guest,” without setting up an account.

But just as importantly, every e-commerce site should have a way for customers to terminate their accounts and should allow them to delete their usernames and passwords from the system. It’s okay to market to previous customers. It’s not okay to needlessly put them at financial risk.

This essay also appeared in the Jan/Feb 05 issue of IEEE Security & Privacy.

Posted on February 10, 2005 at 7:55 AM • View Comments

←Previous 1 … 24 25 26 27 Next→

Sidebar photo of Bruce Schneier by Joe MacInnis.