Let’s be honest, there hasn’t been a lot of news showing up here lately. It’s not to say, though, that nothing has been happening. Far from it, actually. Code has been committed on a regular basis for quite some time, but looking at blog posts, you wouldn’t know it. My sincere apologies.
Secure, Easy Logins
The server code made steady progress and recently reached some development milestones. It is now possible to create an account and log in. Although that may sound like nothing special, an enormous amount of design work and learning went into it. Before Anselus I knew almost nothing about cryptography. The login process is a three-step process which requires a username, a password, and a device-specific challenge-response step.
A simple username and password combination might have been enough in 2003, but the Anselus platform is intended for more than just everyday situations. Multifactor authentication is becoming more necessary, but to be honest, it’s really annoying. Anselus introduces device checking, where a user’s other devices are notified if a new device logs in. Only when the user approves this new device is it successfully logged in. After this first login, no extra work is needed. The best part is that a smartphone is not required.
The server also gives administrators different ways to create an account. The default mode, private, only permits administrators to register a new account. The administrator runs a command and the server generates a one-time-use registration code and gives it to the user. At no time does the administrator have the user’s password. Because the registration code can only be used once, if a malicious actor does use it, it is detected immediately. Public mode, the most lenient of the registration modes, allows anyone to create an account. It is not generally recommended, but there are situations where it could be very helpful. Two upcoming modes are moderated, where the user creates the account and an administrator approves it, and network, which works just like public registration but only for a specific network instead of just anyone. Anselus gives service providers ways to manage a service while maintaining the user’s privacy. Getting the design for registration and logins just right has been challenging but worth the effort.
Identity services became the focus once registration and logins were running as designed. Anselus borrows a number of ideas from the Dark Internet Mail Environment to implement keycards. Keycards are digital certificates which make exchanging encryption keys easy. They associate a person’s workspace ID, their keys, and other basic information in a way that can be mathematically verified and trusted.
The potential of Anselus’ keycards is immense. In addition to the encryption and signature keys used to establish communications between two parties, each keycard also has an extra general purpose encryption key which is public. This means that passwords could be a thing of the past. How? A person enters his/her Anselus address into a form on a website. The web app retrieves the person’s public encryption key and sets up an encrypted session which could only be authenticated properly by that user and no one else. The boost in security and usability cannot be understated: I go to a website, punch in my Anselus address, and I’m logged in. That’s it, and it’s secure, too. While it is true that there are other identity frameworks available, possibly dozens, this has the potential of gaining traction because the security is a side benefit, not the main goal.
All in all, this project gets more and more exciting as it progresses. Until next time, friends.