Entries Tagged "passwords"

Page 26 of 27

Hymn Project

The Hymn Project exists to break the iTunes mp4 copy-protection scheme, so you can hear the music you bought on any machine you want.

The purpose of the Hymn Project is to allow you to exercise your fair-use rights under copyright law. The various software provided on this web site allows you to free your iTunes Music Store purchases (protected AAC / .m4p) from their DRM restrictions with no loss of sound quality. These songs can then be played outside of the iTunes environment, even on operating systems not supported by iTunes and on hardware not supported by Apple.

Initially, the software recovered your iTunes password (your key, basically) from your hard drive. In response, Apple obfuscated the format and no one has yet figured out how to recover the keys cleanly. To get around this, they developed a program called FairKeys that impersonates iTunes and contacts the server. Since the iTunes client can still get your password, this works.

FairKeys … pretends to be a copy of iTunes running on an imaginary computer, one of the five computers that you’re currently allowed to authorize for playing your iTMS purchases. FairKeys logs into Apple’s web servers to get your keys the same way iTunes does when it needs to get new keys. At least for now, at this stage of the cat-and-mouse game, FairKeys knows how to request your keys and how to decode the response which contains your keys, and once it has those keys it can store them for immediate or future use by JHymn.

More security by inconvenience, and yet another illustration of the neverending arms race between attacker and defender.

Posted on July 11, 2005 at 8:09 AMView Comments

Security Skins

Much has been written about the insecurity of passwords. Aside from being guessable, people are regularly tricked into providing their passwords to rogue servers because they can’t distinguish spoofed windows and webpages from legitimate ones.

Here’s a clever scheme by Rachna Dhamija and Doug Tygar at the University of California Berkeley that tries to deal with the problem. It’s called “Dynamic Security Skins,” and it’s a pair of protocols that augment passwords.

First, the authors propose creating a trusted window in the browser dedicated to username and password entry. The user chooses a photographic image (or is assigned a random image), which is overlaid across the window and text entry boxes. If the window displays the user’s personal image, it is safe for the user to enter his password.

Second, to prove its identity, the server generates a unique abstract image for each user and each transaction. This image is used to create a “skin” that automatically customizes the browser window or the user interface elements in the content of a webpage. The user’s browser can independently reach the same image that it expects to receive from the server. To verify the server, the user only has to visually verify that the images match.

Not a perfect solution by any means—much Internet fraud bypasses authentication altogether—but two clever ideas that use visual cues to ensure security. You can also verify server authenticity by inspecting the SSL certificate, but no one does that. With this scheme, the user has to recognize only one image and remember one password, no matter how many servers he interacts with. In contrast, the recently announced Site Key (Bank of America’s implementation of the Passmark scheme) requires users to save a different image with each server.

Posted on July 1, 2005 at 7:31 AMView Comments

Write Down Your Password

Microsoft’s Jesper Johansson urged people to write down their passwords.

This is good advice, and I’ve been saying it for years.

Simply, people can no longer remember passwords good enough to reliably defend against dictionary attacks, and are much more secure if they choose a password too complicated to remember and then write it down. We’re all good at securing small pieces of paper. I recommend that people write their passwords down on a small piece of paper, and keep it with their other valuable small pieces of paper: in their wallet.

Posted on June 17, 2005 at 8:40 AMView Comments

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 PMView 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 PMView 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 PMView 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 PMView Comments

Social Engineering and the IRS

Social engineering is still very effective:

More than one-third of Internal Revenue Service (IRS) employees and managers
who were contacted by Treasury Department inspectors posing as computer technicians provided their computer login and changed their password, a government report said Wednesday.

This is a problem that two-factor authentication would significantly mitigate.

Posted on March 22, 2005 at 9:54 AMView 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 AMView Comments

Sidebar photo of Bruce Schneier by Joe MacInnis.