Regarding a stolen painting:

Mitic remains baffled as to how the drunken daredevil made off with the 30-by-40 inch portrait.

According to the thief, security guards stopped him at the door, but let him leave with the art.

“They asked him if he was supposed to have that and he said ‘Yep!’ and walked off,” Mitic said. “And that was it.”

I wonder how hush-hush the guards were when they learned it was stolen

Humour me.

Imagine I wanted to sign-up for Bob’s coffee roasters website¹ to order some flavourful roasted beans². I click sign-up button, enter my e-mail address and shpping information, and then told to go to my e-mail account to verify my e-mail account. At no point was I asked to enter a password.

I log into my e-mail account and click the verification link, the website then sets a password in my browser’s localstorage. I am assigned a session cookie, and can browse the website normally. I close my browser, relaunch, and visit the website again. I enter my e-mail. The browser takes the password from local storage, and submits it. If the password for any reason is invalid, I must re-verify my email. Otherwise, it lets me in.

Whyyyyy?

Two reasons

1. Password managers are (usually) amazing and incredibly useful, and I would recommend it over this approach for sure (my reasons why are below). That said, I don’t know how popular password managers are to the general public.
2. I read something on, I believe it was hacker news, a comment that talked about a website that only used email to authenticate the user. Apparently customers loved it. I thought that was amusing (and frightening) and wondered if that kind of experience can actually exist securely.

What happens if I change devices

The same thing. You must go to your email account and verify. You would also need to store a device ID so you can map passwords to devices.

What happens if I lose my device?

This is probably fine, minus the loss of your device. Yes, technically anyone with access to your device browser has access to your passwords. But given that your device (phone, laptop) probably has unrestricted access to your email, anyone can just use the standard password reset. When an attacker has access to the device, generally it’s lost cause and you cannot trust that device.

Devices often have PINs, fingerprint readers, passwords, and encrypted drives. That is what should prevent them from accessing your private data.

Caveats

If you’re site has an XSS vulnerability, it’s game over. This is by far the biggest downside I see with this approach. There are mitigaton techniques, but you have to be perfect 100% of the time. (XSS is pretty bad even if an attacker wouldn’t be able to steal your password, but password is pretty much winning gold).

Some other caveats I see:

1. Devices need access to email
2. Browser support for local storage
3. Private browsing may affect access to local storage
4. You still need to protect the password in the database
5. Devices/browser shared between multiple people
6. If a user has multiple accounts, that may complicate things a bit

¹: My imagination is shot and some coffee would be good right now

²: Man, I can realllly go for a coffee

My mind has been thinking about a few events that happened during the past week at work. These events range from Amazon AWS S3 going down to some errors in our application that was causing a “this should never happen” to.. happen. I have been catching up MSDN’s Cloud Design Patterns to see what can we do about it because all the events had the same basic problem - how do we deal with services going down?

Resiliency is an easy thing to forget partially because we are accustomed to incredibly high uptimes in our infrastructure. But even some of the best in the industry make mistakes, and network outages, database downtime, and failures still happen. Our code must be able to catch and deal with these issues.

I am reminded about how difficult it is to code to that. It is not something that can be solved in a design pattern. It is about inspecting every point of your system that makes an external call and saying “what if this calls fails?” and being able to recover from that. It’s incredibly tedius. You will inevitably try to convince yourself that the odds are extremely low. The truth is it’s almost certainly going to happen. Luck is never on your side when the enemy is time.

I also reflect on how important it is to think about this early in the process because dealing with failure gracefully might require building things differently.