The trouble with passwords

Security breakins leading to password exposure have been in the news this week, what with LinkedIn.

My last blog, about how biometrics are only a partial solution, was prompted by this. Actually, prompted by a National Public radio item on the LinkedIn breakin.

Security is getting mindshare when it hits NPR.

LastPass makes me feel a bit complacent, since I now have big different random passwords on nearly all of my sites, and, supposedly, LastPass never actually holds the unencrypted passwords. Supposedly the passwords are encrypted before being sent to LastPass.  So, a breakin at LastPass should NOT lead to password leakage, unless the crypto is poor.  (On the other hand, LinkedIn apparently encrypted its passwords, but did not salt them - so their crypto WAS poor.)

(Actually, I must admit: I only recently started using LastPass. All of my newer sites used LastPass, but I still had some old passwords that were pre-LastPass, human memoragble and therefore weaker.  None of the them were the same as my LinkedIn password, but I changed them anyway. I hope I changed them all... It's quite a challenge to scan your password list looking for weak passwords, given the interfaces. That is something I'd like automated - but then again, so would the bad guys.)

If LastPass' crypto is not broken, then the weakness for LastPass is at my end: looking at the passwords via my browser.

But, anyway...

If LastPass' security is good enough - nothing is secure, but probably it is better to look for other problems to solve - then what needs fixing more? I.e. what cloud services need improved security more urgently?

Well... LastPass supposedly doesn't access unencrypted passwords, but account aggregators like Yodlee and Mint do.   These services log into many, many, bank and other accounts, so that you can see all of your financial data in one place. Of necessity, if they do this while you are offline,
then they have access to all of the passwords.

Ouch!

If Yodlee or Mint are broken into, then thousands, perhaps millions, of people's financial information is exposed.

(Interestingly, the old Wesabe, a dead company in this area (now open source), was adamant about not keeping passwords - or, rather, encrypting. Decrypting passwords only at your PC. But IIRC this meant that Wesabe could only aggregate when your PC was connected. Which loses if your only PC is a laptop, often not connected overnight.)

OK, how do we address this:

* we want no single aggregator to store all of the passwords, so that they can be broken

* aggregators necessarily, given the state of the art [*], have to send passwords (albeit over SSL)

How about:

Split the passwords.

Let no single cloud service store all of the password.

Let the aggregator service be stateless wrt passwords. Let it access 2 or more password storage services, and get all parts (both halves) of the passwords needed to access the user accounts.  Access. Download. And then forget.

Breakins at any single one of the password storage services would not disclose all (encrypted) passwords.

A breakin at the aggregator would not disclose stored passwords.

But... if the aggregator was pwned, then the badguys could be intercepting the passwords on the fly.

---

We can get ornate, and imagine websites "calling back":

* aggregator  tells PWstore1 and PWstore2 that it is about to access website W
* aggregator accesses website W
* website W calls PWstore1 and PWstore2 to check

etc.

Plus, of course, generic challenge/response instead of entering passwords into boxes.

 ---

Passwords would need to get longer so that the split passwords are not so vulnerable.

---

There's probably some fatal flaw in what I propose above. Embarassing.  But I no longer care to remain silent and avoid embarassment.

"Google Chrome to Phone" is not affiliated with Google???

I installed "Chrome to Phone" on my Android device, from the Google Play Store. At this store, Chrome to Phone is described as <<< Google Chrome to Phone Google Incorporated Top Developer >>> I installed the related Chrome extension from the Chrome web store: <<< Google Chrome to Phone Extension (3412)Fun from chrometophone-extension@google.com >>> However, when I try to click the link on the "Google Chrome to Phone" icon by the address bar of my browser, I get: <<< The Chrome To Phone application on your computer is requesting access to your Google Account for the product(s) listed below. Chrome to Phone (chrometophone.appspot.com) - not affiliated with Google If you grant access, you can revoke access at any time under 'My Account'. The Chrome To Phone application will not have access to your password or any other personal information from your Google Account. Learn more The application that directed you here claims to be "Chrome To Phone". We are unable to verify this claim as the application runs on your computer, as opposed to a website. We recommend you deny access unless you trust the application. >>> So, which is it? "Google Chrome to Phone" is not affiliated with Google? Or have I been hit by malware that is intercepting this? More likely, Google acquired the app, but did not update everything. Sigh.

Biometrics are the smallest and least important part of replacing paswords

Marketplace Tech Report for Thursday, June 7, 2012 | Marketplace.org


Just heard the item about the LinkedIn security failure, passwords, and the researcher working on password typing rhythm.

Had to write because I am sick and tired of biometrics folks like the password typing rhythm guy saying they could solve password problems - when there is a fundamental limitation that means that they only solve the least important part of the problem, and that not very well.

First, terminology: "biometrics" means anything that measures something about you Like your password typing rhythm, your fingerprint, your retina scan.

The problem: anything like biometrics can be recorded and replayed by a bad guy.  If exact replay is detected, the bad guys are smart enough to vary it.

What this means: biometrics, such as password typing rhythm, is only useful if the device that is being used is PHYSCALLY SECURE as well as clear of viruses, and if it uses encryptionto talk to whatever remote server like Google you are trying to authenticate to.

For example: probably a bank can trust a fingerprint reader, or a password typing rhythm system, if the readers are kept at the bank.

But the bank should NOT trust password typing rhythm or fingerprints that are read from a remote device that is not physically secure.  E.g. say that I go to an internet cafe in Mexico to use the web while on vacation: the fingerprints or password typing rhythm read there should NOT be trusted, because some bad guy may own the computer that is reading them.

Stuff you own is intermediate: your desktop and laptop PCs, and your cell phone, are not completely physically secure.  Not as secure as at a bank.  But more secure than an internet cafe in Mexico. Plus, they may have malware, such as a keyboard logger, recording your password typing rhythm and giving it to the bad guys.

(By the way, my own most recent expertise is in preventing such malware.)

Here's the bottom line:

* Remote servers cannot trust biometrics like password typing rhythm.

** not unless they can trust you to have a physically secure device, and secure communications.

* If you give your biometrics to multiple sites - like the 528 sites one of the folks you interviewed has passwords on - then chances are that one of them will have a security breach, and the bad guys will know your biometrucs.


Is it hopeless?  No!


The way forward is what Google is already starting to do: working with your cell phone as well as your PC to authenticate securely.

E.g. now, when I log into Gmail on my PC, Google texts my cell phone as a cross check.

Now,if I lose both my cell phone and my laptop PC together, the bad guy might have both.  But this is just a step.

One of the next steps will be for the biometrics, e.g. the fingerprint, to be read on your cellphone.  And for your cell phone to reply to Google saying "Yes, I have read Andy's fingerprint".  And for the cellphone to automatically contact my PC, saying the same.

Worried about losing your cell phone?  Make the device that reads the biometric into something you wear, like a bracelet or amulet on a necklace or ring.  I call this a "security amulet". You might regularly rub it, e.g. to read your fingerprint.  (We might even imagine surgically implanting it.)

Actually, when we do this, we don't really need to have the cell phone send the biometric back to Google, or any of the other 528 web sites. Perhaps your security amulet will read a fingerprint, while mine is listening to the "core rhythm" of my heartbeat.  And perhaps once a day it may check my  password typing rhythm.

We still need to worry abut losing the biometric device / cell phone / security amulet - although it is harder to lose something like your wedding ring, it is possible.  There's no panacea here, except to note that we can make devices that are tamper resistant - if they are lost or stolen, and a bad guy is trying to break in and steal your security data, it can (1) erase itself if it detects a clumsy attempt to break in, and (2) make it hard to break in in an undetectable way  E.g. giving you, say, 48 hours to realize that you have lost your security amulet / wedding ring.

The biometrics is only a small part of this.  Its the least important part, actually:  more important are the security protocols between your cellphone / security amulet, and all of the servers you want to use securely.

Google's texting of a code to your cellphoneis just a start.  But its happening. Slowly, but it's happening.

So, PLEASE stop interviewing biometrics folks as if they can solve security problems. Biometrics is only the smallest and least important part of the problem.

A make pattern

test: run-test1 run-test2

.PHONY: run-test1
run-test1: test1.x
        ./test.x
test1.x: test1.cpp ...
        gcc -o test1.x test1.cpp ...

Of course, in a decent build system, this is a macro Build_Targets_For("foo.cpp"), rather than having to write them all out by hand. Scons may not be the best, but it avoids much clutter.

.x

I once gave a bad revioew to a UNIX book that suggested that executables should have a .x suffix.

But I find myself using the .x suffix, in large part because I want to automatically .hgignore (or .cvsignore, or ,gitignore) executables created by tests.

I *do* only tend to use .x for test executables. I prefer not to have to type in foo.x to use the tool foo. Although sometimes I will create a script foo that invokes foo.x.

I sometimes wonder about a suffix path as well as the directory path.

Wanted: per-directory .hgignore

One of my big complaints about Mercurial is that it only supports /.hgignore.

It does not support .hgnores in sub-directories.

I have a lot of legacy code with .cvsignores scattered around.  In CVS, when you move the directoriy from one place to another, the .cvsignores just work at the new location.  (Although moving the CVS directories around is a challenge.)  Whereas in Mercurial, wehen you move a subdirectory, you also need to go and fix any patterns in the project .hgignore.  :-(

Because of this, one is tempted to use patterns that are possibly too broad.  I have several times found myself .hgignorre'ing files in one part of the tree because they matched a pattern intended for a different part of the tree.

Status versus log

Many people - e.g. the people who want me to edit version control history - really want a status, rather than a log.

A log tends to record diffs. Deltas. Changes, What I did or am doing.

A log message for a version control system tends to describe what has changed between this and the last.

Note that a version control log is less complete than a human log.  A human log may describe what you tried, but which failed, and which you did not commit.  Sometimes I think it is as important to record that, as it is to record what worked well enough to release.

Oftentimes what people really want is a status.  "Here's the state of the project - this works, this does not".

Note that in a human log, sometimes you may step back and write a status.

Tools like hg bisect really want a status.  E.h. hg bisect only wants to attempt to test on versions that are known good - good enough to have run some sort of test in the past.

Statuses change.  "Passes all tests" may become false, if more tests are added.