Identity redux

Today I spent an embarrassing amount of time trying to figure out why I couldn't use SSH with my new GitHub account, before figuring out that I needed to log in as git@github.com and not myaccount@github.com.  Evidently I'm not the first person to stub a toe on this, but it got me thinking about one of the earliest topics on this blog: identity.

A natural way to think about identities and logging in is that your username is your identity and there are various ways of authenticating that identity, for example

• a password
• a password and a second factor such as a magic number sent via SMS or generated by a smartcard
• a public/private key pair
• (in some SSH contexts) hostname or IP address and public/private key pair

Others are possible, of course.  What the GitHub experience made clear to me is that the "username" part is secondary, at least as far as SSH is concerned.  The important part of authenticating SSH is the key.

As far as I can tell, GitHub is taking the public key offered during the SSH handshake and looking it up to get the account, and thus the account name.  That's probably also why when you try to upload a key you've already uploaded (e.g., to check that you haven't taken complete leave of your senses while trying to figure out why you can't log in), the error message is "already in use".  It doesn't say by whom, even when it's you.  The rule is one account per key (but potentially multiple keys per account).

This suggests a different approach to identity.  As far as the web is concerned a key, and in general an authentication method, is an identity.  This is more or less the case with Bitcoin wallets, and to some extent for PGP and other email privacy schemes, but even then for the most part we talk about using keys to establish an identity.

Let's run through some data modeling to see how this all fits:

• People, identities and resources to be accessed (such as accounts) are three different things.
• A person can have multiple identities
• Multiple people can use the same identity, though that's often not a good thing
• A resource can be accessed by multiple identities
• In general, though not in the case of GitHub accounts, an identity can access multiple resources

There are two reasons I find this key-is-identity model attractive.  One is that your web server doesn't see you, it sees the credentials you present.  It really only sees the key, or at least only ought to look at it when verifying identity. Yes, it may also know things like which IP address someone is connecting from, but even though that information can sometimes be a useful hint that something's not right, it's ephemeral, not part of the identity. 

The other, maybe just the first with a different emphasis, is that it loosens the connection between resources and people.  It might be nice to think that Gavin Belson logged in to your server with username gavin@hooli.com and the proper password, but it's better to think that someone logged in with those credentials.  You know that gavin@hooli.com logged in.  You don't know that that was Gavin Belson (I'm looking at you, Gilfoyle).  The identity that matters here is gavin@hooli.com, not Gavin Belson.

Except that gavin@hooli.com is associated with a password, which can change without changing what we mean by the username (or, one would hope, it's associated with a password and a second factor, such as a phone or smartcard).  Are we really going to say that if Gavin changes his password, we're dealing with a different identity?

Let's try "yes".  The whole point of changing your password is that anyone who knew your old password won't know your new one.  We presume that, at least at first, only Gavin knows the new password.  From the point of view of the system Gavin is logging in to, (gavin@hooli.com, old password) is indeed a different identity from (gavin@hooli.com, new password) because there are potentially different sets of people who could be each.

What if Gavin uses his phone as a second factor?  There are a number of ways to do that, so suppose that the server sends him a text with a magic number when he tries to log in and expects to get that number back as part of the login process.  That provides a reasonable assurance that whoever's logging in has both Gavin's password and his phone (assuming the text isn't intercepted).  If Gavin does have his phone, it also informs him that someone, hopefully it's actually him, is trying to log in.

Suppose Gavin switches phone numbers but keeps his password the same.  Should we consider that a new identity?  I think the same logic still applies.  If Gavin's password has already been compromised and he changes his phone number, then someone might manage to grab the old phone number, and so forth.  In any case, the set of people with access to the old phone number is potentially different from the set of people with access to the new one, so different identity.

If you're carefully tracking who did what to a resource, you need to track the authentication.  A different means of identification, even for the same user name, means potentially different people.

One logical conclusion of this is that username is not identity.  So what is it?

It's a name.  Seems plausible, at least.

Names are yet another concept, distinct from person, identity or resource (personae are yet again distinct, but this is getting complicated enough as it is).  For example, gavin@hooli.com sure looks like an identity, but when you send email, you're really just sending it to an address which is connected to an inbox (which is a resource).

There may be more than one address connected to a given inbox.  Likewise, the name I use to log in to access that inbox may or may not be an email address (for example, my ISP provides me with an email address I never use, but if I want to see mail for that address I log in with a username that's different from the email address).  Likewise for however you logged in to send me mail.  If we're using secure mail then, regardless of everything just mentioned, you'll encrypt the mail to your recipient's public key and sign it using your private keys.  The keys are the real identity, because we trust them.

I'm comfortable with this, too.  I've come to think that one of the most fertile sources of bugs is confusing names with identities (see this post for some a bit more on names).  Names are convenient, but ideally they're only used to look up what you're really interested in.  I personally prefer systems in which renaming things is cheap, if only because I generally come to hate the names I come up with to start with, no matter how much careful thought I gave them.

The way you generally do this is to assign a unique id -- typically a hundred bits or so of random gibberish -- to each resource that can be named, and then maintain a map from name to id.  When you access a resource, say an account, by name, you look up the name in that map, stash the id somewhere and use the id to access the object.  If the name → id map changes, you still have the id and you can still find the same object.  The system can maintain as many names for a given object as it sees fit, but each name corresponds to only one object (at least at any given time).

Summing up

• Web servers don't see people directly.  They see the credentials that people (and other servers, for that matter) present.
• The credentials are distinct from who (or what) uses them
• The names we use to refer to resources are distinct from the credentials that can be used to access them.

I think public key systems line up well with the key-is-identity model because the public key is the single identifying item.  In a password scheme, whether you consider (username, password) or just username to be the identity, you are giving two pieces of information, both of which are durable, but which must generally be kept separate because one of them is meant to be secret.  The password isn't truly private.  The host you're logging into has to know it [technically, it only has to store a secure hash of the password together with a bit of randomly-generated "salt", but from a security point of view that's only a bit better since it still has to see the password during the login in order to do the hash and comparison, and password files can be stolen and attacked brute-force offline --D.H. Feb 2017].

In a public key scheme, there is still a public part and a private part, but you present only the public part.  The private key remains truly private.  It's generally stored encrypted, guarded by a passphrase that you only use locally.  If you change the passphrase, no one else needs to know.  Authenticating means exchanging ephemeral information, much of it randomly generated, that will never be used again.  All of this makes it much easier to keep the private key secure for long periods of time, so the public key can serve as a durable identity.  Since it's the only durable thing that other parties see, it's sufficient to serve as an identity by itself.

There's a long way to go yet, but it seems likely that the world will gradually shift to key-as-identity, or something at least as strong.

I am not my IP address

It appears that the major ISPs have decided to launch an "education campaign" about copyright violation.  If their filters determine someone using your IP address is uploading copyrighted content, you will get a series of increasingly firm warnings telling you that you may be breaking the law.  And, as some have pointed out, to let you know that your ISP is watching what you're doing and to leave a nice, visible paper trail saying "you were warned".

I say "copyrighted content", but in practice that probably means video, .mp3 files and such.  I doubt that they're trying to catch people uploading the text of The Hunger Games or whatever, even though that's just as copyrighted as, say, Thrift Shop.

Before going on, I suppose this is a good opportunity to repeat the disclaimer: I don't speak for my employer.  I speak for myself, at least on a good day.  Let's throw in the "I am not a lawyer" spiel while we're at it.

On the one hand, I'm not horrified by this.  It certainly seems like a better approach than previous attempts to crack down.  The ISPs certainly have some right to do such things.  Your agreement with your ISP is a private contract.  As much as we value free speech as a principle, when you're paying a private company to convey your speech, they get some say.  Restrictions imposed by your ISP are not laws of congress.  Not to say that there shouldn't be some sort of protection, but any first-amendment case would have to be aimed at the laws regulating ISPs, not at the ISPs themselves.   Outside the US, your mileage may vary ... hmm ... how do you say "your mileage may vary" outside the US?

Likewise, the studios and record labels have a right to protect their copyrights (that is, the copyrights they acquired from the people who actually created the content).  Whatever we may think of studios, record labels, publishers and such, there is a legitimate business to be done in financing, publicizing and selecting content.  The question is whether it's done well or badly, ethically or not-so-ethically, and in what cases it makes sense for the creator to take on that role personally or hire it out.

That said, I'm leery of the basic approach of tying activity to an IP address.  In a typical household, any of several people may be using a given address, and the person paying for the service is generally not going to be aware of what every person in the household is doing at all times.

Neither is it safe to assume that the only people using the IP address in question are living in the house to which the IP address is assigned.  There are plenty of insecure wifi routers out there.  For that matter, there are plenty of deliberately insecure routers out there.  Is a coffee shop with free wifi also liable for whatever its guests choose to upload?

Nor is it that hard for someone uploading copyrighted material to disguise that fact, or plausibly deny it -- and it's a good bet that someone who makes a habit of distributing copyrighted material illegally would positively enjoy confounding The Man.

In short, it looks very easy to get false positives (someone notified of suspicious uploading when it's not their fault) and false negatives (someone up to no good going unnoticed).  If the idea is to "stop piracy", it's unlikely to work any better than previous attempts.  On the other hand, if the idea is to remind people that copyrighted material is protected by law, or start a discussion between the person legally on the hook for the internet bill and the rest of the people using it, that could probably work.

Behind all this is the issue in the title: to what extent can an IP address be identified with a person?  A reasonable analog in the real world is the distinction between a car's license plate and a person's driver's license.  A license plate is associated with a person, and that person bears some legal responsibility for what happens with that car, but if you loan your car to a good friend and that friend gets pulled over for speeding, the points go on the friend's license, not yours.

If the friend runs a red light and gets caught by a camera, though, you'll get the notice, as registrant of the car.  What happens next is a bit unclear, particularly if your maybe-not-so-good friend doesn't feel inclined to step up.

The ISP case seems more like the camera case than the pulled-over case.  Just as (generally) only the car can be positively identified, only the IP address, and not the person, can be positively identified [that is, the numeric address is known for sure ... there are ways, at least in theory, to spoof addresses in the sense that the packets sent to and from that address aren't going where the system thinks they're going].  Again, if the idea is to educate people about copyright law and remind them that yes, companies take this seriously and, by the way, we can see what you're doing with your IP connection, that's probably OK.  But if it comes down to fining and arresting people, the IP address involved had better be just one piece of evidence in a stronger case.

Not that that's much comfort if you have to hire a lawyer anyway.

Forbes on passwords

Wandering through the web (but not necessarily figuring it out as I went along) I ran across a slide show in Forbes on the subject of passwords, with what seems to me mostly reasonable advice.  Some highlights, mostly common-sense stuff that bears repeating:

• Change important passwords frequently and don't reuse them
• Use different passwords for different purposes.
• Important passwords (e.g., for bank accounts) should be unique. 
• Less important accounts can share passwords, but be aware that if one account is compromised you should consider all of them compromised.
• Don't choose a password that's ever appeared elsewhere.  This rules out memorable phrases like "We the people of the United States of America".
• Passwords should contain nothing personally associated with you (basically a version of the previous item).
• Password managers may be useful.  The advantage is you can use random gibberish and the manager will remember it for you.  The disadvantage is that if the master password is ever cracked, you're completely hosed.
• Use HTTPS when logging in.  HTTPS encrypts all connections and uses digital certificates to ensure that you're really talking to whom you think you are (just exactly how secure this system is is a whole other can of worms, but for now let's assume it's basically OK). You can tell if you are because web sites with it start with "https://" instead of "http://" and browsers now indicate whether you have a secure connection
• Don't type your password into anyone else's machine.
• Assume that a public WiFi access point is just that, public (the actual slide says to avoid it entirely).  If you're not using an encrypted connection of some sort (HTTPS, SSH, a VPN or such) assume that anyone can see your network traffic, including passwords you type when you log in.  Also assume that any random person can see anything that's publicly shared on your computer (another fine can-o-worms).
• Don't depend on passwords generated by web sites or random software.  Even if everything's on the up-and-up, it's very easy to get password generation wrong, typically by using a weak random number generator (see this post for more on generating passwords).
• Archive your important passwords in case of catastrophe, for example by writing them down on a piece of paper and storing it in a safe deposit box that can be opened in an emergency.
• In general, if you're going to record a password somewhere, do it on a physical medium separate from your computer (see disadvantage of password managers, above).

There are also a few items that don't seem actively harmful, but probably don't help greatly either

• When replacing letters with numbers and such, use non-obvious numbers, e.g., r7place instead of r3place.  This will add a few bits of entropy, which is good, but not really good enough on its own.  If your base word is in a dictionary of 500,000 words and you replace up to three characters with one of 15 replacements, you have about 30 bits of entropy, which is not that much.
• Add a number to the end of sentence-based passwords "for extra uniqueness".  Adding a number adds about three bits of entropy.  Meh.
• Scramble a password when writing it down.  This will make it harder, but not impossible, for someone who finds your written password to figure out the actual password, but it will also make it harder for you to come up with the actual password at two in the morning when you discover you don't quite remember how you scrambled it and the Very Important Site locks out accounts with more than three login failures.  Of course, you could write down how you scrambled it ...
• Deliberately misspelling words can make passwords more secure.  Yes, but not very much more secure.
• Use a sentence with lots of words, and include punctuation.  In theory this can work, but in practice people come up with much-less-than-random-words, particularly if the sentence actually makes sense.  Also, surprisingly many systems get indigestion if you try to use a long password.

Building a better password

[I've updated this post slightly to reflect the back-of-the-envelope calculation in this post suggesting that 100 bits of entropy is probably more reasonable than my original statement that 48 bits was "not bad".  Under the assumptions in that post, a 48-bit password would take on the order of microseconds to crack --D.H. Feb 2020]

I've recently complained about the irritating nature of the password strength checkers that have been popping up everywhere, so I feel obliged at least to try to analyze the problem and offer solutions.  This is leaving aside the question of whether password authentication is a useful approach at all.

Fundamentally the real measure of password strength is how many passwords you'd expect to have to guess in order to get the right one.  A more formal version of this is the notion of bits of entropy.  If you had a list of all possible passwords in your scheme, I could identify any particular one so long as I could get answers to a series of yes/no questions, for example:  "Is it in the first half of the list or the last?",   "Is it in the first half of that half or the last?" and so forth.  The number of such questions I need is the number of bits of entropy.  Twenty questions means twenty bits, etc..

If I know that your password is either "0" or "1", you have exactly one bit of entropy.  If I know it's an uppercase letter, lowercase letter, digit, "$" or "%", there are 64 possibilities, so you have 6 bits of entropy.  If I know it's two such characters, you have 12 bits, and if it's seventeen such characters you have 102 bits, which is not too bad.  Someone trying to guess your password would have to guess about two thousand billion billion billion passwords, on average, before stumbling on yours.  That may seem like a lot, but keep in mind that the current network of Bitcoin miners can try on the order of a hundred thousand billion billion hashes -- roughly the same problem as guessing a password -- every second.

[Don't assume that guessing a password requires typing it in to the same text box you have to use.  If someone steals the right data from your service provider, they can throw as much computing power as they've got at guessing the passwords.  Quite possibly they'll be happy enough just to try a few thousand weak passwords for each account, since that will crack depressingly many, but attacks like running through the OED with simple substitutions of letters for numbers are absolutely feasible as well, even on fairly ordinary hardware.]

This is assuming that you picked eight characters at random.  If I knew instead that your password was either "F1%ldN0t3$" or "sasssafras" (maybe I'd watched you read your password off a piece of paper with only those two words on it but couldn't quite see which you were typing), then you have only a single bit of entropy, even though both passwords are not just eight but ten characters long and one has plenty of non-letters.

More realistically, if I knew you'd picked an uncommon English word and maybe changed some of the letters to numbers, you'd have somewhere around two dozen bits of entropy.  That's not nothing, but keeping in mind that each added bit doubles the number of passwords a cracker has to try, it's nearly a billion billion billion times weaker than the 102-bit scheme above.

The fundamental flaw of password strength checkers is that they can only look at the password you gave them.  They have no idea what other possible passwords you might have chosen.  The assumption is that if you're forced to jump through enough hoops you'll be forced to expand your parameters, but in fact it's possible to generate passwords in a secure manner using only letters, and or to generate them insecurely in a way that will still satisfy any strength checker out there.  Which is why I half-grimace, half-laugh when I see the "password strength indicator" jump from "poor" to "great" as soon as I type a number.

Now, it's perfectly possible to generate completely random 17-character passwords.  The problem is that something like "qcrQf1x2" or "u%js%hPQ" is a pain to try to memorize, so most people will fall back to picking a "hard" word and maybe altering it a bit.  However, as xkcd points out, it's possible to do a lot better by using random short words.

For example, here's a kind of clunky way of producing a random, memorable password:

BIG HONKING DISCLAIMER: This is just for demo purposes.  The second site I mention uses http, not https, so in theory anyone could be looking in on your session.  Even with https, the sites might be logging all your traffic and recording the results you come up with.  I personally seriously doubt they would, and it's hard to imagine they would be able to connect the dots and figure out what you were using the generated password for, but if you really want to be on solid ground, get the source, look it over, run it locally and use something like /dev/urandom or D&D dice to generate the random input (23d20 will give you close to 100 bits ... not that I would have any idea at all what "23d20" means).  There are also smartphone apps that do more or less the same thing, I believe.

[I last checked that the recipe below worked on 28 Feb 2020]

With that out of the way:

• Go to this site and copy the random string you see there (e.g., 60990FFC250C).  If for some reason you don't like what you see, just reload.
• Go to this site.
• Type some short number and a space into the Challenge box and paste the random string from the first step in after it (e.g. 123 60990FFC250C)
• Type anything at all into the Secret box (e.g., "secret").  This doesn't have to be hard to guess.  The real entropy is coming from the random string (alternatively, put any number you like, a space, and anything else into the "challenge" box and paste the random bytes into the "secret" box).
• Press the Compute with SHA-1 button.  Again, the cryptographic details of how strong SHA-1 is don't matter here.  You're just converting a random number to short words.  A simple table lookup would do just as well.

In the Response box you will see six short words followed by some hexadecimal gibberish (in this case, WOVE COOT SLEW WIT SIGH I (FE2D 5F7B 22CD BC39)).  Each of those words represents just over 10 bits of entropy.  We'll need ten words in all, so repeat the procedure but this time just take the first four words (I got FIRE CUFF GALA MINK from A4B455FEFFE7BFAD).

You can play around with this formula to get words that are easier to memorize, or type, or are just more to your liking.  If you reorder your words or try typing in several different things instead of 123 or secret and then picking what you like, you're decreasing your entropy, depending on what criteria you're using to filter out passphrases you don't like and whether your attacker knows what kinds of phrases you like.  If you just try a few different secrets until you see something that seems memorable, that should be fine.  If you do something like sort the words (and your attacker knows only to try sorted lists of words), you've lost almost 22 bits of entropy, which wouldn't be good.

Once you've selected your words add a random punctuation character, number, capital letters or whatever makes your site's password strength checker happy.  Voila!  Your password is now Wovecootslewwitsighifirecuffgalamink5? or whatever.  This isn't great to have to type, but it's pretty secure as passwords go, and probably better than trying to remember something like C;cTbfThoO4ePFTt or 67EE386A205C4563DB8908A6C4.

If your site's password checker imposes an 8-character limit (and, incredibly enough, some do), cry.

This password madness has got to stop

It's well known that people like to choose bad passwords, and for years other people have suggested rules for making passwords more secure.  I'm not really sure why it should be happening now in particular, but it seems that every site that has a password must now jump on the bandwagon and have a password policy enforcer.

And of course, they're all a little different.

Fortunately there are plenty of possibilities.  Here's a do-it-yourself guide in case you think your site needs one.  First, pick any two of

• The password must contain at least one number
• The password must contain at least one lowercase letter
• The password must contain at least one uppercase letter
• The password must contain at least one special character

Next flip a coin to pick one of the remaining two to disallow.

Now pick a minimum length.  Back in the day, when computers were much slower than they are now and it wasn't fairly easy to get a gazillion computers to cooperate (with or without the owners' consent), the recommended minimum length was eight characters.  Today it should probably be more like 12 or 14.  So make sure the minimum length is at least six.

Now set a maximum length of 8.  Why a maximum, given that all other things equal, longer passwords are stronger, and the whole point of the exercise is to encourage strong passwords?  Don't know.  Probably whoever put the database together remembered the old eight-character rule and decided that should be the maximum.  But 8 is a magic number for passwords and everyone else does it.

Finally, add an arbitrary hidden restriction.  For example, if the password has to have a number, make sure it can't be the first character (yes, I ran into that one).  If it has to be a special character, quietly disallow '$' and '!'.  Something like that, just to reduce the strength and make people work a little harder.

Voila.  You now have a password policy.  If I did that math right, there are three dozen basic policies, times however many arbitrary rules there are, so there are easily hundreds of possibilities.  Chances are fair that your poor user will never have encountered your exact policy before and never will again.

Chances are also fair that once they jump through all your hoops (bonus points if this is all happening on a smartphone or tablet), your poor user will have never come up with that particular password on the spot before.  That's good, since sharing passwords can be dangerous.  The only drawback is that poor user is liable to forget this ad-hoc password within five minutes of logging in.

So urge them to write it down "some place safe."

Then have them pick three or four secret questions and answers for when they have to reset the password next time they log on.  But that's a different rant.


If you feel you need further security advice, you can always consult a real expert.

Defending your reputation (for a small fee)

Some time back, when I had a somewhat different vision of this blog, I ruminated about how one might model reputation.  Whether or not the model is any good, taking some time to think about what reputation might be was a useful exercise.  Re-reading the posts in that thread, one of the more useful observations was:

We try to control our reputations (at least)

• through our actions
• by controlling access to information about us
• by influencing people's interpretation of the information (we think) we know

Of those, we have the most control over the first, though perhaps more effort is devoted to the third.  The second has its own special quirk:  It's possible for information to disappear from the web, if all permanent copies can be removed, but the safe assumption is that information only accumulates.

Nonetheless, there are companies in the business of helping people control access to information, and thereby their reputations.  A fool's errand?  Probably not.  There are several services that reputation protection services can and do provide:

• Monitoring what you look like on the web.  If someone posts something slanderous about you, you may not find out until it's too late, unless you're constantly monitoring the web -- or have someone doing it for you.
• There are various online lists and databases that you can sometimes have your personal details purged from, but who has the time?
• You can't erase information from the web, particularly if it's a rumor that's already spread far and wide, but you can respond and try to counter it.  In this sense, protecting a reputation is just old-fashioned PR.
• If you choose to, say, put all your purchases and reading selections and reading up for your friends to peruse, you might want to use a different identity to mention that you're reading World Domination in Six Easy Evil Steps or to purchase that 1.21 gigawatt laser.  But if you don't already know that, a service may not be of much help.

What's less clear to me is how much any of this is worth to private individuals.  If your ex has just posted those embarrassing videos of you from the last christmas party, it's not going to help much to learn about it in a report form your reputation service.  It would seem it's the PR function that's most useful in such cases, but unless you're directly in the public eye you probably don't have call for that.   If you do need it, you're not going to get it online for a small monthly fee.

I'd liken it to search engine optimization.  If you're doing serious business online, you definitely want it, along with real marketing expertise.  If you're blogging in a web.backwater, probably not so much.

Or so I hope.

More reading on identity

As a companion to the previous post, Joe Andrieu's blog, apart from its own merits, is also a fine jumping off point into a whole community of people thinking long and deeply about such things as what identity means on the web and how to empower* people to take charge of data.  The immediately relevant post is Self-managed Identity, itself part of a series Introducing User Driven Services.


* I generally cringe when I hear words like "empower," but I use it here because I believe it's appropriate and they really mean it.

Letters of introduction

As part of my never-ending quest to catch up on things I ought to know already (right up there on the list with reading all the great works that I've never gotten around to reading), I did a little brushing up on single sign-on schemes.

The basic idea of single sign-on is simple and good: I don't want to have to type a username/password all the time, and I don't want to have to keep track of which password I used for which account. The second item is particularly bad, since even though there are ways to let people have passwords without storing the passwords themselves, not everyone seems to know how to do it (the techniques are only a few decades old after all). So that means either keeping track of lots of passwords, or using a few and running the risk that one insecure site gets compromised.

(Logging in by sending a password to a server is kind of bogus anyway. Stronger schemes use passwords only to locally unlock the secrets of some sort of strong crypto which then handles the real authentication. There are also smart cards and similar which use strong crypto to generate a secret with a limited lifetime, tying a login, assuming the crypto works, to a physical object and a point in time.)

So, how does a single sign-on service work? Basically such a service depends on a way for some other system to vouch for you to the system that you're trying to log in to:

• You log in once with a particular server
• That server gives you (or your browser) a token (or cookie, or ticket, or whatever you like). That token effectively says "so-and-so was able to present me with such-and-such credentials -- generally a username and password but possibly something more substantial -- at such and such time"
• You (or your browser) show that token to the system you're trying to log in to.
• That token has enough crypto mojo in it to allow the system you're logging into to verify that it really came from some party it trusts, that it hasn't been tampered with, etc.
• Assuming that the identification in the token matches a known account, you can now be logged in.

There are variations. For example, in OpenID, you give the server you're trying to log in to a URL representing your identity. That server chases the link and finds out who's vouching for you. It then checks with that party. Typically that party will ask you to log in to it and make sure that you trust the server that asked it to do that. The two servers then securely agree, effectively, that yes you did log in.

The young Charles Darwin carried with him on the voyage of the Beagle letters of introduction, as was common practice in those days. By presenting the appropriate letter, he was able to obtain lodging, safe passage and other such benefits. The letters were signed by people the benefactors knew and trusted and let them know that Darwin was also someone to be trusted. The signature a was crucial part of ensuring that the message really came from whom it said it did; people paid more attention to signatures then than we typically do now.

Is there a connection between this fading and quaintly antiquated practice and modern digital technology? Well, they don't call it a digital signature for nothing ...

What's my mother's first dog's maiden name?

I can remember my login, but I can't remember my password. "No problem," says the site, "Just tell me that secret you told me when you set up the account. What was your first dog's name?" So I type in ... oh wait a minute, I can't tell you that ... and the site sets me up with a new password. Pretty slick, yes?

Well, not quite. Since lots and lots of sites are doing this, I've got two main choices:

• Use the same small set of questions and answers everywhere.
• Use different questions and/or answers.

Using the same everywhere means not having to remember as much. If I make up a bunch of answers and/or use different ones everywhere, then I have to remember what I made up. Basically, I'm up against the exact same problem as with passwords themselves, except now there are two weak spots for attackers to exploit: My actual password, and the questions guarding my password.

Of the two the password is probably a bit more secure, assuming I haven't used one of the 500 worst passwords of all time (unfortunately, some people seem to confuse scatology with security). City of birth? There's a good chance it's one of the top 100. Mother's maiden name? Not exactly classified information. First dog's name? There are a lot of Maxes and Buddies out there.

Now I'd say most sites don't let you reset a password directly. Typically they'll email some gibberish to the address you registered with and you use that to log in and reset the password for real. But in that case, why bother with the rigmarole? Whatever real security there is comes from putting email in the loop.

All in all, it's a classic example of a more complex system looking more secure than a simple one, but actually being less secure.

Signing webmail

While looking up something on S/MIME, I ran across one of those little "hmm ... interesting point" points. How do you digitally sign webmail?

The problem isn't that mail sent through a web interface is somehow harder to sign. The question is who do you trust to do the signing. The whole point of webmail (and one version of "the cloud") in general, is that you can access it from anywhere on any device. The whole point of digital signatures is convincing everyone that only you could have done the signing. Two great tastes that don't go so great together.

If I only send mail from a particular box, I can just leave my private keys in a file on that box (password protected, of course) and use a mail client running locally. I tell the mail client my password, it fetches the keys and signs my message. This approach is as secure as my box and the firewall it sits behind.

If I'm in a cybercafe or using one of those airport internet kiosks that I've never, ever seen anyone use, I don't want to copy my secrets onto a local drive (assuming I even can) or otherwise hand them over to a the browser directly. You don't know where that thing's been.

The next candidate would be the webmail server. Hand it my keys, once, very securely. Then I log in to my webmail and send a message from wherever. The server signs it for me without revealing my secrets to the browser.

There are a couple of problems with that. One is that I'll need to be careful logging into the server. If the browser is actually a password-stealing trojan horse, then whoever is running it can grab my login and forge whatever they like under my identity. Another is that if the webmail server is ever compromised, the attacker doesn't just get my key, but a whole treasure trove of keys to go cracking for weak passwords. That's a problem for the people running the server, but it's also a problem for me since the server is a nice, big, visible target.

There are ways to make logins trojan-horse-resistant, for example smart cards that generate a fresh hunk of random digits every so often, but these are not widely deployed. The bottom line is that any server with your keys on it is only as strong as its authentication system, and most of those aren't that strong.

What would be better? The basic trust issues are clear enough, but the kind of mental ju-jitsu needed to think through all the various counter-measures and counter-counter-measures is hairy in the extreme. True black belts are relatively rare, and I'm not one of them. But from what I can tell an airtight solution would probably involve some kind of smart card that you could plug into the device you're actually using (the pocket-thing would be a candidate, but then, it could probably send signed mail directly). The server would then need a conduit through which it could send data up to the smart card and get signed data back.

And even then it would do well to check that what you signed was actually what it sent you.

OpenID picks up steam

How many user names and passwords does a person need, anyway?

The first answer that springs to mind is "one". I don't think this is necessarily the right answer, though. I probably don't want to have the same credentials attached to my bank account as to my more frivolous pursuits, just like I don't want to have my safe deposit key open my front door or unlock my bicycle.

On the other hand, one of the annoying facts of web.life is that seemingly every single thing you use wants a user name it can identify you by. And if you give a mouse a user name, he'll probably want a password to go with it ... This gets old quickly.  While "one" is probably not the right answer, "dozens and dozens ... I don't even know how many" probably isn't either.

In practice, of course, most people come up with a few user names and passwords and use them over and over again. That's the equivalent of having the same key fit lots and lots of little locks, and as long as there's not anything too valuable behind any of those locks, it's probably OK. On the other hand, if anyone steals that key, you end up having to change lots and lots of locks.

In the virtual world it's a bit worse, even. While you have the only copy of a physical key, every service you sign up for potentially has a copy of your user name and password. I say "potentially" because there's a standard technique (hashing) for not knowing a user's password, but what are the chances of every single service using it correctly, or at all? [Note that if a site just stores a hash of your password (as it should), it's still possible for an attacker to figure out your password, buy guessing and seeing if any guess matches the hash.  If you have a good password this is much, much harder (assuming the site is using a "cryptographically strong" hash, but it's not impossible]

The correct answer to "how many user names and passwords" is probably "as many as I like, but no more than that," realizing that in some cases you'll need, or at least should need, a completely unique ID whether you like it or not. So how do we do that?

Your typical login goes like this:

• Who are you?
• I am Sir Galahad of Camelot
• What is your quest?
• I seek the holy grail
  
• What is your password?
• python
• Hmm ... do we know a "Galahad"? Does the password match our records? Yes? You may pass ...

Now change this just a little:

• Who are you?
• I am Sir Galahad of Camelot
• What is your quest?
• I seek the holy grail
  
• How do I know you're Galahad of Camelot?
• Ask http://roundtable.ct/galahad
• Hmm ... http://roundtable.ct/galahad, do you know this "Galahad"? (Galahad deftly turns around, whips out his web-enabled Sword of Righteousness, logs in to roundtable.ct and tells it to accept the bridgekeeper's request for authentication) Yes? Do I trust this roundtable.ct? I suppose so. You may pass ...

Dodgy analogies aside, this is the basic approach behind OpenID [Note: that's openid.net, not .com] What's happened is that instead of keeping track of names and passwords directly, the bridgekeeper, being OpenID-aware, agrees to take an OpenID provider's word for it. Galahad, for his part, only has to be able to tell his OpenID provider (roundtable.ct in this case) to accept the bridgekeeper's request. The OpenID URL serves as his user name and whatever procedure he uses to log into his OpenID provider -- maybe a password, maybe a smart card, maybe a retina scan or whatever -- is good enough for the bridgekeeper.

If you like all that, there's still the little question of getting people to use the scheme. This requires two things to happen. One is getting sites to to provide OpenIDs. This isn't hard -- more or less anyone can do it. The other problem is to get sites to accept OpenIDs.

Some sites aren't very fussy. A lot of places are more concerned with having some sort of name to track than proving that that name belongs to anyone in particular. They'll let anyone make up a random name and password. The OpenID equivalent would be accepting any URL as an OpenID, so long as it follows the standard.

Other sites want to tie an identity to a given email address. You know the drill: You provide an email address when you register, that email address gets an email with a magic link in it, you chase that link and only then is the account activated. The OpenID equivalent would be to accept URLs only from sites you knew required that sort of validation. There are many such. In particular, blogger.com does. Any blog URL can serve as an OpenID, so I can provide http://fieldnotesontheweb.blogger.com as an OpenID.

As usual there is more to OpenID than the short summary here, but that's the gist as I understand it. OpenID aims to scratch an itch that clearly needs scratched, and it seems to be getting some traction. I've run across OpenID login options on several mass-market web sites, including CNN and, more geekily, on SourceForge.net. Since blogger.com also accepts OpenID, you'll also see it on blogs attached to major sites.

On the provider side, besides Blogger, AOL, Flickr, Orange Telecom, Yahoo! and several other blogging services, it seems MySpace has jumped on the bandwagon (and Facebook hasn't). There are also several sites that specialize in providing and managing OpenIDs, notably including one run by VeriSign. OpenID maintains a list, and there is also a commercial directory aimed at promoting providers and OpenID-enabled sites.

[OpenID is still a thing, but it clearly hasn't taken the world by storm.  Amusingly, the Wikipedia article's section on "Adoption" was last updated in 2009 -- D.H. June 2015]

Degrees of access control

Following on to the previous post, I wanted to explore just what kinds of control one currently has over one's data and could potentially have. Here are some possibilities:

• None. If I post an anonymous comment somewhere, anyone can read it, copy it, quote it or whatever they want. If I've been careful, it can't be traced back to me, so conversely I (generally) have no claim to it.
• Open access, but traceable origin. This blog is strongly tied to my online identity, which in turn is more-or-less strongly tied to my real identity. If I were to write something libelous, I would have to answer to it, but on the other hand if someone were to try to pass something here off as their own, I would have a believable claim to authorship. Note that an anonymous message can still be traceable, if it's digitally signed but the identity behind the signature is kept secret.
• Access by software key. Now things get interesting. If I send you an encrypted message, only you have access to it. But once you decrypt it for your own access, there is nothing technically preventing you from doing whatever you want with it. For example, you could charge people to look over your shoulder and read it off your screen, without giving them permanent access to it. As always, copy protection works by tying information to a physical object. This leads to ...
  
• Access via dedicated hardware. This is access by key, but the key is strongly tied to a physical device, which presents the data only in analog form. One successful example of this is the set-top box. If "trusted" hardware devices are widespread, this actually gives quite a bit of flexibility -- to whoever holds the keys. One could grant permission to a group of devices (say, all of my family's music players), or transfer permission between devices.
  

The point of that last point is that DRM is not binary. There is quite a bit of potential for flexibility in control. The contentious issue is not control per se, but whose control.

How do you know I wrote this?

[This one came out a bit disjointed.  Re-reading, I'm not really sure why I mentioned TLS for SMTP servers as having much to do with digital signatures as a SPAM-fighting device.  I also seem to imply that DNS spoofing could point you at, say, a fake banking site without your browser knowing.  The certificate checking in TLS would catch that.  DNS spoofing could perhaps be used in more subtle ways to get your browser to accept a bogus update to its trusted certificates list, but that's a much smaller attack surface.  Anyway, the general drift, such as it is, is still good, as is the conclusion --DH 7 Sep 2010]

As I go along, one of the things I'm trying to figure out is why doesn't everyone have a cryptographically strong keyring? I mean, here's this really well-established, well-studied and as far as our best minds can figure out highly secure way of doing several useful things. In particular, it can establish to a practical certainty that whoever signed a particular piece of data knew a particular secret key.

But no one uses it.

OK, people do use it. The major example, not surprisingly, is that e-commerce sites generally use a certificate in their HTTPS handshake. Your browser will even tell you this if you know where to look (in Firefox you use the little lock icon next to the address at the top which, if you're like me, you forgot all about).

So as long as you remember to check for that, and no one's fooling around with DNS behind your back (see below) and your browser hasn't been compromised (see below), you're good. Note that this is meant to establish your trust in the server. The server will trust you on the basis of a small password (and your incentive not to give it away).

Outside that crucial and curiously asymmetric case, examples get a bit sparse.

At least one major online brokerage (and so probably all of them) will set you up with a digitally secure ID. Whatever overhead or unfamiliarity digital keys may have is worth it if there is enough money at stake.

I've mentioned that widespread use of signatures would probably take a pretty big bite out of spam (um, maybe that's not the best metaphor). I don't see any signs of traction on this, outside of some SMTP servers using certificate-based TLS (quick -- which ones and how do you tell?).

For a while I used to sign all my posts to a mailing list I was on. Then I switched to a different setup and never got around to turning signing back on. No one cared.

Even in an environment like a standards committee, where the members are speaking very publicly and representing companies with money at stake, the posts are generally not signed (at least not in the committees I've had direct experience with). You're trusting the committee members to keep their small passwords safe and the world at large not to care much about standards committees. Which, admittedly, is a pretty safe bet.

OS vendors use strong crypto to make sure that updates are from where they say they are, though I do recall once or twice seeing instructions to the effect that "You may see a message complaining about a bad or missing certificate. Ignore it." OK .... I'm getting a bit of a mixed message here, but OK ....

I couldn't remember whether my Firefox plug-ins were signed, and I couldn't find any indication of it for the ones I had installed, so I went to the Firefox extensions site and checked a couple more-or-less at random. These were in the web development section, so they did things like muck with the HTTP headers you send or munge the content coming back. Stuff you might want to be particularly sure was kosher before installing (or not -- the whole point of Trojan-horse-like attacks is that they can be disguised as anything).

Unsigned, of course. Even if they are signed, do I understand the signing protocol in question well enough to trust it? Not really. I take it on faith that the folks at Mozilla have thought it all through. I particularly hope they've thought the HTTPS stuff through. I'm sure I'd hear about it if they hadn't.

Not that most people will care, but Eclipse plug-in security is even more of a formality. I'm not sure I've ever seen a properly signed third-party plug-in. I probably have, but I don't remember where or when. Security of development tools is not of entirely academic interest. Ken Thompson had a bit to say about that.

What the heck is going on here? If you've got a reasonably mature technology and a problem it seems to fit well, yet no one seems to have adopted it, then either

• The problem isn't the problem it looked to have been
• There's more adoption than one might think
• Something else is solving the problem well enough to prevent major outrage
  

In this case I think it's a combination of the last two. In e-commerce, there actually is strong crypto involved, just woven in seamlessly enough you only see it if you're looking for it.

That's good, but SSL/TLS authenticate a server, not a person. To take a classic example, if I'm dealing with someone on eBay, their certificate means I can be pretty confident I'm talking to eBay. I can also be pretty confident that eBay at least made this person type in a password in order to sign on. I mean, I had to when I logged in. Beyond that I need eBay's feedback mechanism to help decide whether I want to do business with them.

Returning to the title, how do you know I wrote this? It probably goes like this:

• You believe that fieldnotesontheweb.blogspot.com is controlled by Blogger. We put remarkable trust in DNS, and despite attempts to poison it (or spoof by playing nasty games with Unicode), that trust seems to be repaid. So far.
• You believe that no one has stolen my blogger ID (or if they did, I would be able to get the account blocked until everything got straightened out).
• If you've read more than one post, this one (I hope) seems like it was written by the same person as the others.

Other situations behave similarly. I trust DNS to make sure my bank is my bank and that the servers involved in authenticating my HTTPS connection with them are who they say they are. We trust our OSs and browsers to do the right thing with updates. We exercise caution in dealing with phishy-looking emails.

We trust that email that says it's from someone we know really is, and we're generally right (the exception being mail from oneself -- either I sleepwalk or the occasional spammer is spoofing the From: line to be the same as the To: line). That makes a simple whitelist a reasonably good spam filter.

In short, we have a typical case of engineering in the real world. The status quo is a patchwork of partial solutions yielding results that are significantly non-optimal, but not quite bad enough to leave room for sweeping reforms. That's probably not going to change until the bar for going secure is very, very low, and/or people decide that having strong crypto is worthwhile even if no one else uses it.

A strawman access control model

This is so simple I'm sure it's been invented already, but I can't be bothered at the moment to track down where. [Ed. Note: It's pretty close to, but not necessarily exactly the same as row-level security and cell-level security in modern databases]

• The world consists of a set of records/objects (I'll call them objects, risking confusion with other definitions).
• Pick a query language by which you can select a subset of this universe.
• With each party that can access the world, associate a number of queries, for example
• A read query. Any query that party makes must return a subset of the results of its read query. If it contains anything else, the entire query is rejected with a simple "access denied" error.
• An add query. Notionally, execute this query after tentatively making the addition(s). If all additions are in the result, the addition commits. Otherwise it fails with a simple "access denied" error.
• A delete query. The records to be deleted must be a subset of the results of the delete query. Otherwise ... you know the drill.

As always, an implementation doesn't actually have to make the queries in question, as long as you can prove it acts exactly as if it did.

Minimal as this is, it may be enough to usefully control access to a personal datastore. For example, I could allow anyone who successfully authenticated as a travel agent add permission to, say, (type=calendar-entry and tags contains travel and tags doesn't contain public). I would grant random people read access to (tags contains public), delete access to nothing and maybe add access to (type=comment and tags contains public).

By default my travel agent's entries would be private unless I did something to make them public. I can blacklist people by reducing their add and read queries, and conversely I can allow privileged access by expanding their queries.

What I'm doing here is basically punting almost all of access control over to the query model of the datastore and to the authentication model that establishes the identity of a party and finds its associated metadata.

A major assumption is that in order to be useful, the query model has to be pretty powerful anyway. In other words, figuring out what objects to grant access to (and what additions/deletions to grant permission for) is no harder than getting useful information out of the datastore in the first place.

Access control models have query models hidden in them one way or another, so why not use what you've already got?

Refining the persona/reputation model

Previously I asked whether it was worth breaking up the M:N relation between personae and attributes. My personal bias is to break these up whenever there's a natural name for the resulting link or (and this is closely correlated) whenever the link might naturally have relations outside the two linked entities. My further bias is that this is generally true.

I also asked whether opinions are different from other assertions.

I think these can both be answered by dropping attribute, action and opinion, adding

• An assertion is a claim made by a persona

and reworking the relations as follows:

• A person (1) assumes an identity (N)
• An identity (1) is assumed at a time (N)
  
• An identity (N) is as a persona (1)
• A persona (1) makes an assertion (N)
• An assertion (N) is made at a time (1)
  
• An assertion (1) is about a persona (0 .. N)
  

Instead of attributes, actions and opinions, we have various assertions, e.g.,

• I assert (at time t) that the sky is blue (plain assertion, not about anyone)
• I assert that I am handsome (one way of bestowing an attribute)
• I assert that my friend is homely (another way)
• My friend asserts that my opinion can't be trusted
• My bank asserts that I made a deposit this morning (assertion of an action)
• I assert (at time t+1) that the sky is not blue (changing my opinion)

This model is probably missing a key ingredient or two, particularly a means of granting access to assertions, but it seems enough to support reputations. E.g., if I assert that I have $1,000,000 in the bank but my bank asserts I have $0, that will influence my reputation. Reputations can be built both by tying assertions to the outside world (You're convinced that my bank is trustworthy) or by studying the relationships between them (X has a history of lying about his bank account).

Modeling reputation

Joe Andrieu has some interesting points about reputation on the web, among them that no one seems to have a concrete model for this crucial concept.

Going on that basis, and probably re-inventing a few wheels along the way, here are some thoughts:

• You have a reputation with someone as something
• A reputation is another person's interpretation of what they associate with you, including
  
• Attributes ("Statutory")
  
• Actions ("Case-based")
• Your reputation with third parties and their reputations as judges.
  
• Everyone will have a different view of those things, and even if two people somehow had the same view, they will almost certainly interpret it differently.
• We try to control our reputations (at least)
• through our actions
• by controlling access to information about us
  
• by influencing people's interpretation of the information (we think) we know
  
• One way to control this access is to take on a persona. The most obvious way is via a pseudonym, but subtler forms are also common. For example, we tend to separate, say, our business correspondence from our personal correspondence.
• This control is very incomplete.

A bit more on personae:

• A given person will take on many personae
• Some personae are taken on by many people, either sequentially (The Dread Pirate Roberts) or concurrently (Bourbaki)
• The association between a person and persona is an independent entity. If nothing else, it has a life cycle (on this day, Peter Parker became Spiderman)
• The knowledge (or insinuation) that two personae are the same person can make a drastic difference in certain cases (X is just a sock puppet for Y; Someone on a company's message boards is actually the CEO)

Translating this into old high ERM, here are some entities that appear to fall out:

• A person is a flesh-and-blood person.
• A persona is a public image of a person.
• An identity is the association between a person and a persona.
• An attribute is something the owner of a persona asserts to be true about it.
• An action is something a persona is publicly seen to have done.
• An opinion is something one persona asserts to be true about another persona (rendering an opinion is an action).

and some relations:

• A person (1) assumes an identity (N)
• An identity (1) is assumed at a time (N)
  
• An identity (N) is as a persona (1)
• A persona (M) carries attributes (N)
• A persona (1) takes an action (N)
• An action (1) occurs at a time (N)
  
• A persona (1) renders an opinion (N)
• An opinion(N) concerns a persona (1)
• A persona (1) may change an opinion (N)

This is only a very basic model, of course, and there may well be other models that deal with reputation as well or better. Some questions:

• Is it worth breaking up the M:N relation between personae and attributes?
• Is rendering an opinion any different from making any other assertion? Probably not.
• What's the best way to handle group reputations. In a case like Bourbaki, there is only one persona and the present model will handle it. In a case like "the legislature is incompetent", both the reputations of the legislators and of the legislature as a whole are involved.