Wednesday, April 20, 2016

Bikes and Pacman Synchronicity

Bikes and Pacman Synchronicity

I happened to see two works with an amateur perspective in the feeds recently. 

Velocipedia: 'crowd-sourced and technically error-driven drawings' of bikes. "" 

'Studying the Language and Structure in Non-Programmers’ Solutions to Programming Problems' "" 

Thursday, May 7, 2015

Unverified Identities on Websites

Unverified Identities on Websites

Earlier article for context: 

During my re-implementing to simplify the email identity thing, I realized that it could be useful to allow unverified identities, and I have now implemented that. At first, I tried simply not verifying email adresses of certain patterns; for example emails ending in "". Which works, of course, but I feel hesitant about it for a bunch of reasons. 

Firstly, an email is a lot to type just to get an unverified nickname. If you want to try a site, it should really be even simpler. Of course, many sites don't even tell you that they give you a temporary identity, tracking visitors by cookies. Yeah, you're now by law in many places required to inform the user that they're being tracked. But it would also be good to have the user be a little more aware of what their id is, so that they can be more recognizable in pages where that is useful. So, I'll either allow typing in a nickname, or have it be generated for the user, probably something readable. 

Secondly, it may be prone to user confusion. Well, everything is, but of course I'd like to minimize that. I can even have a separate page to set an unverified identity, which I hope will give maximum clarity and simplicity for everybody. 

Thirdly, it doesn't 'feel' good, architecturally. It's coat-tailing, re-purposing. Alternatives are not clearly demarcated, which I feel is a cornerstone of good software architecture. 

Fourthly, I'd like to implement it as a separate module from the email identity, for simplicity, and to be able to exclude the email identity module in favor of something else, like OpenId or Facebook identities, if an application so requires. 

I think I'll add a little clarifying detail on the 'unverified' identity idea. It will not be the case that the access token cookie is not verified. It will still be a signed access token that the server has to issue and check. One could of course dispense with that too, since the id is not really verifed to start with, but I think it's best to limit identity access tokens to only be available via the server. Perhaps to limit their number. But there's also the advantage of not having separate paths. The 'outer' format of the tokens is always the same; and the signature is always checked. Simpler, less room for mistakes resulting in security problems. 

And finally, some low-level implementation details, which don't really matter, but might still put a little meat on the conceptual bones. The token content is JSON, of the form {"id": [id], "utcs":...}. An email identity is of the form {"email": ""}. An unverified identity is of the form {"unver": "anything_goes_here"}. This is the 'id' field, in the JSON object that also contains the "utcs" field, which holds the number of seconds since 1970 of the moment the server issued the token. Having a time-of-issue allows expiration to be checked. 

Next, perhaps something about how to implement this in Java, or more on sending email links with access tokens. I hope this scheme gets implemented in place of the awful username/password scheme on the internet, unless something better is available. 

Thursday, April 30, 2015

Simplest Email Identity

Simplest Email Identity


Ah, last of the month again. Why not write about something useful? 

One things that bugs me, is how web sites do identity or login in ways more or less clumsy and terrible. 

But let's not get into rant mode, I'll just tell you of a simple solution. And _then_ maybe go on a rant. 

It's really simple: show an email input field. Send access token to that email as a link. When user clicks link and reaches your web site, add the token, or a variation of it, as a cookie. Done. Now you have a cookie that verifies the email identity, and can be used to authorize operations. 

Note that the access token can be simply a signed message. That way, no storage is needed on the server. So no statefulness _at_ _all_. So no scalability limit here. 

Encode a time of issue in the access token, and have a max age for some operations. Sill no storage needed. Just keep your server clocks somewhat accurate. 

The email can be used for easier reissuing of a new token. No need to fill it in again. Can even be sent out automatically before expiry, or when user accesses site, for instance tries operation requiring an access token younger than the one set as cookie. 

The email input field should have the type='email' attribute. This way, the browser can check syntax, or even fill in the email for the user. So 'signing up' for a site could be done with minimum effort, and then only require waiting for an email that should be arriving shortly. 


So, that's the gist of it. I've implemented this in Java, and am currently re-implementing it, simplifying it further, and I might publish more details helping to implement this, or even code or a jar to run a demo of such a site. 

So, there it would obviously be much better if this was handled some other way, perhaps as a standard interaction with browsers, where the user is asked if it wants to reveal his or her identity to a site asking for it. Or partially reveal. 

And/or there could be trust networks; e.g. there could be sites issuing or guaranteeing identities. There already is standards and players here, of course; OpenID, Facebook. But then you'd have to trust them. And Facebook reveals too much, I'd say. There should be steps, so that you have the option to only establish an identity without going further with details like names and friends. 

Now, you might say that an email is already too much. But a user could have a secondary email just for testing sites out. A problem then might be transferring to a real email if you want to be known more as yourself, e.g. if the site provides social services where people can get to know you by email. 


There is the ever-present safety and security considerations. What can of damage can an attacker do to the described scheme? 

Using the signed-token implementation, scalability is of course a first defence. 

A serious issue with email verification is always sending too many unwanted emails to people; even though there is not much an attacker could get out of it, except hurting the reputation of the targeted site. Rate limits per email address, is one thing. This requires storage and synchronization, thus hurting scalability. 

An attacker could create unlimited numbers of email accounts, perhaps using a mail server specifically for this purpose, and register each of them automatically. Using the encrypted-token implementation, no storage is used, so this attack is not so useful in a first stage, but the attacker might go on to use whatever resources are afforded by the site to each identity. Per-domain limits might help. 


Additional small things to help. 

Email apps could have separate folders or filtered tabs for identity mail, like 'forgot password' messages. 

Email apps could throw away reset link messages after they are used or after they're expired. Or perhaps just default to discarding them after a month. 


Now for the ranting. (Separate article?) A web site should not... 

A web site should not require a username. This means the user must come up with, and remember a user name. Come on, I've better things to do. We all have, I hope. 

A web site should not require a password, if there is any other way to do it. 

A web site should do this in their own interest. How many simply balk at signing up, and just leave the site? 

A web site should not require a real name on sign-up. In addition to requiring even more extra work, unless auto-fill can be leveraged, a user might not want to tell. A user may want to gain confidence in the utility and seriousness of a site before contributing private information. 

Worst case when a web site requires a username and a password: you forget them both. You'll have to: 
(*) guess username/password. Get told 'username or password wrong'. 
(*) what now? Have to guess which one is wrong. Site could've told if it didn't know the username. Of course, you could still have guessed somebody else's username. 
(*) click 'forgot username'. Fill in email. By hand, no auto-fill. Click 'send', or whatever. 
(*) wait several minutes for mail. 
(*) fill in username; there not being a link in the mail doing this via URL params. 
(*) fill in password again, it was not saved in browser's local storage. 
(*) Get told 'wrong password'. 
(*) click 'forgot password'. Fill in email. By hand, no auto-fill. Click 'send', or whatever. 
(*) wait several minutes for mail. 
(*) now you'll have to reset your account password, filling in password twice. 
(*) you'd think the site could log you in from there, but no; now you have to log in again. 
(*) Done, if you've managed to stay. Now you can check the status of your ticket or do whatever trivial thing you needed to do. 


Odds and ends: use HTTPS, further automation, fine-grained authorization, finding similar existing implementations, compare to existing non-similar implementations and thinking about tweaks in this direction, password managers as a solution, what is the 'culture' and sociology that has made this bad state a reality, etc, etc.