eRacks Systems Tech Blog
Open Source Experts Since 1999
A Sad Day – the Demise of Persona / BrowserID
A Sad Day – Mozille BrowserID / Persona Dies
It’s a sad day – the best of the federated Authentication Providers, without its own agenda or privacy issues, has shut down, due to the public’s apparent lack of interest and / or awareness.
Mozilla Persona, which started life several years ago as BrowserID, was the only one of the OpenAuth-based Authentication providers that didn’t insist on being logged in to a commercial site in order to be authenticated by proxy at the time – with all the privacy issues that entails.
Although it’s no secret that The Public is notorious for not caring about (or not even being aware of) privacy (or at least sacrificing it in favor of convenience), it’s unfortunate that the Mozilla Foundation has chosen not to spend the time, effort, and money to educate the public, as it has chosen to do with its other products.
Here are some relevant excerpts from the shutdown page:
FAQs
A website I use requires Persona for login, what should I do?
You will need to contact the site owner and ask about their plans for migrating away from Persona.
Mozilla staff can find more information about the progress of migrating internal sites on this mana page.
Why is persona.org being shut down?
Our metrics show that usage of persona.org is low, and has not grown over the last two years.
Hosting using vps hosting plans at the level of security and availability required for an authentication system is no small undertaking, and Mozilla can no longer justify dedicating limited resources to this project. We will do everything we can to shut it down in a graceful and responsible manner.
What will happen in the meantime?
Between now and November 30th, 2016, Mozilla will continue to support the Persona service at a maintenance level: Security issues will be resolved in a timely manner and the services will be kept online, but we do not expect to develop or deploy any new features. Support will continue to be available on the dev-identity mailing list and in the #services-dev IRC channel.
All websites that rely on Persona will need to migrate to another means of authentication during this time.
What happens after that?
On or after November 30th, 2016, the services hosted by Mozilla on persona.org will be taken offline. This includes the persona.org website, the javascript shim, the fallback IdP and identity bridges, and the hosted verifier.
Mozilla will retain control of the persona.org domain and will not transfer it to a third party. This is a security measure to protect websites that have not completed their migration away from the service.
All user data stored on the persona.org services will be destroyed, including registered email addresses and password hashes. Since the privacy of user data is of utmost importance to Mozilla, we will not transfer it to any third parties.
What about the code?
All of Persona’s code — core, bridges, shims, and more — is open source and remains available on github. Though this marks the end of Mozilla’s direct involvement in Persona, we encourage others to continue learning from and building upon our work.
Migration Suggestions and Guidelines
The following alternative login options are available for sites migrating away from Persona. We will continue to update this page throughout the year.
We intentionally designed Persona to expose email addresses rather than opaque identifiers, which should ease the transition to other systems that provide verified email addresses.
Mozilla-hosted sites may find additional, staff-login-specific migration options on the internal mana page.
Delegated Authentication Providers
Many large email and service providers offer delegated login for third-party applications, including Google, Facebook and GitHub. Indeed, we have found that many sites currently using Persona also offer login via one or more of these services. While these services do not offer equivalently-strong privacy guarantees to Persona, they are a convenient and secure choice for users since they avoid the creation of a site-specific password.
We plan to offer delegated authentication with Firefox Accounts some time in 2016. If you’re interested in adding Firefox Accounts as a login option to your site, please reach out to us on the dev-fxacct mailing list.
Site-Specific Accounts
Many web frameworks offer password-based user accounts functionality out-of-the-box. Although it requires users to create and remember yet another password, it can be a good choice for users who do not have (or do not wish to share) an account with a delegated authentication provider.
For existing users who previously authenticated with Persona, you could consider authenticating them through Persona again to confirm their email address, then prompting them to create a site-specific password.
Passwordless Email Login
As an alternative to setting a site-specific password, you can allow users to login directly via email link, as described in this article and implemented by libraries like passwordless. This can avoid the security implications of users having to create and manage another password, and may be a good fallback option when used in combination with delegated authentication providers.
Self-hosting Persona
Since the code for Persona is open-source, it would be possible for reliers to self-host an instance of the service that is dedicated to their own use.
This approach is not recommended most reliers. Persona has a large and complex codebase that has not seen significant development in several years, and Mozilla will not provide security or maintenance updates after 30th November 2016.
More?
We encourage affected reliers to document any alternative solutions here and to discuss them on the dev-identity mailing list, so that others can benefit from their experience.
- The Portier open source project attempts to replicate much of Persona’s user experience, while being easy to self-host, even on the free tier of PaaS providers like Heroku. Similar to Persona, Portier supports identity-bridging to Gmail. It falls back to passwordless-style login links for everyone else.
Taken from:
https://wiki.mozilla.org/Identity/Persona_Shutdown_Guidelines_for_Reliers
We at eRacks wil be looking into Portier for our own usage, as well.
j
joe January 9th, 2017
Posted In: authentication, News, Open Source
Tags: Firefox, Mozilla, Privacy, Software Freedom
Putting SSH Keys to Work
There may be situations where you’d like to login to a remote machine via SSH and not have to enter a password to do it. Perhaps you have some sort of automated file transfer that makes use of SCP. Or, perhaps you frequently login to the same machine and get tired of having to enter a password each time. Whatever the reason may be, an attractive alternative to using passwords involves making use of cryptographic keys.
To give you a general idea of what’s involved, you’ll first generate a public/private key pair. Your public key is what you would copy to every machine you want to be able to log into. You can think of the public key as the lock on a door to a house. The reason why we call this a public key is that it’s safe to share it with the public, just as the lock on your door is safe to display from the outside. By contrast, your private key can be thought of as the key that fits into the lock. Unlike your public key, you should never copy it to machines that are either untrusted or to machines that you yourself don’t administer — this would be a bit like placing the key to your front door outside your house for strangers to use! Anybody who possesses your private key can access every machine to which you’ve made your public key accessible, so exercise extreme caution and guard your private key with your life.
SSH makes generating your keys very simple. From the command line, you’ll simply enter the following command:
$ssh-keygen
You’ll then be asked a series of questions. Accept all the defaults. If you don’t desire to password protect your key pair (which would require you to enter a password when you use it), hit enter when asked for the password, without typing anything in. At the end of the process, you should discover two new files in ~/.ssh, id_rsa and id_rsa.pub, where ~ stands for your home directory. From here, you’ll copy your public key (id_rsa.pub) to every machine you wish to log into and append its contents to a file called ~/.ssh/authorized_keys, where ~ stands for the home directory of the account you wish to log into.
To test your newly generated key pair, try to connect to one or more of the remote machines you copied your public key to. You’ll find that you’re sent straight to a command prompt, without the need for a password.
Now, there are situations where using keys without passwords can potentially be hazardous, so some significant thought should be given to the circumstances in which your key pair will be used. For example, I will never copy my laptop’s public key to my personal server at home, because if my laptop is ever stolen, the thief (if he knew how to use *NIX) would not only have access to all my local data, but would also have complete SSH access to my network at home, since he would have my laptop’s private key. Thus, I choose to sacrifice convenience for security in that particular situation. As with all things in life, the amount of relative security versus convenience is a trade off, so make sure you choose wisely.
Enjoy!
james November 21st, 2008
Posted In: authentication, security, ssh, unix
Tags: authentication, key, linux, private, public, ssh, ssh-keygen, unix