HN user
Email: conor [at] allthingsauth.com
If you email, please mention you found me on HN :)
I reply to every email that I receive, but making it easy for me to reply by asking for something specific will get you a quicker reply!
Any comments I make are my personal opinion, etc, etc.
Heyo! Developer of 2FA Notifier and author of the article here.
Happy to answer any questions and have a larger conversation about the best way to get average internet users to enable 2FA on their accounts.
Any and all feedback/thoughts/comments appreciated!
I had been wanting to make something like this for years! This looks really cool. I hope to give it a try on my next project.
Gotcha. It will likely be...a while before I get around to writing a Safari extension, but I am certainly open to it!
I honestly don't know the first thing about creating an extension for Safari. I wish they would just get on board and support the WebExtension standard #wishfulthinking
Thanks for the feedback!
Clean data is definitely going to be a challenge for this project moving forward. I've discussed several ideas in other comments in this thread, so check those out if you are interested.
It does look like inbox.google.com is missing from our data set. We have an open issue to make sure that all of the Google products are added [1].
The messaging that is currently shown there is definitely wrong too because inbox.google.com does support 2FA. We have another issue for handling the "unknown" state when the domain simply is not in our data set [2].
What type of messaging and UI do you expect to see when the extension is unsure whether a given site supports 2FA or not?
Feedback from the community will really help improve the extension! Thanks for sharing your thoughts!
Gotcha. If you happen to use Firefox, I published the extension to the FF store yesterday too [1].
I will definitely take a look at your PRs. I see that you linked them below. I plan to review all of the outstanding PRs in the twofactorauth.org project to see if there are good data cleanup/improvements that I can take advantage of too.
[1] https://addons.mozilla.org/en-US/firefox/addon/2fa-notifier/
It does look like inbox.google.com is missing from our data set. We have an open issue to make sure that all of the Google products are added [1].
The messaging that is currently shown there is definitely wrong too because inbox.google.com does support 2FA. We have another issue for handling the "unknown" state when the domain simply is not in our data set [2].
What type of messaging and UI do you expect to see when the extension is unsure whether a given site supports 2FA or not?
Also, have you had the chance to see the UX for a site that does support 2FA? We currently have over 1,000 domains in our data set, so there is bound to be a service that you use. Feedback from the community will really help improve the extension! Thanks for sharing your thoughts.
I released an update that fixes the notification on www.facebook.com. Check it out and let me know what you think!
The extension is now accessible in the Firefox store [1]!
Please shout if there are any weird bugs in FF. I do test it in Firefox before publishing, but Chrome is my main browser so I catch things there more quickly.
[1] https://addons.mozilla.org/en-US/firefox/addon/2fa-notifier/
Thanks for the feedback! I just released an update that correctly supports www.google.com and www.facebook.com.
Thanks for the positive feedback! There are 2 main articles in the 2FA series left to write (Push 2FA and U2F/WebAuthN), but there are a ton of other posts I have bouncing around in my head. Join the email list if you're interested in getting updates!
I'll definitely give your post a read too!
Have you found it effective publishing on Medium vs your own blog? I've been considering cross posting my articles for additional exposure. Curious to hear your thoughts.
I am not a core committer for twofactorauth.org (yet! I hope to become one!), so I cannot say whether they will accept a PR like that. However, there is an open issue discussing this topic that is worth reading over [1].
2FA Notifier has a bit of an easier job since we don't have to render anything or make it searchable (as of today). I would happily review any PRs along these lines! The data is currently hard coded in a Typescript file, which makes it really easy to update [2].
I plan to document criteria for contributing data to 2FA Notifier like this, but just haven't had the time. One entry per PR would be ideal if you are motivated to contribute!
[1] https://github.com/2factorauth/twofactorauth/issues/1025
[2] https://github.com/conorgil/2fa-notifier/blob/master/src/typ...
That is frustrating. I have been contributing to the twofactorauth.org project, but I am still new to the community there.
It is a really great resource of information with over 1,000 sites as of today. I am not aware of any other data sources that could provide similar information, but if you know of any, please do share!
2FA Notifier uses twofactorauth.org as a data feed, but does not rely on that data alone. I have made updates to the data already to help it work better for the use-case that 2FA Notifier is trying to solve.
I am looking to create a community around the support of data for 2FA Notifier. We would still use the twofactorauth.org data as a main source and contribute changes back to that project. However, I can see 2FA Notifier having a different set of criteria and processes so that we could move more quickly to get the data into production so that it is useful for users of 2FA Notifier.
Will you contribute data to the 2FA Notifier project? I can reach out to you offline if you're interested. I'd love to chat!
We need some guidelines for proper 2FA implementation.
I could not agree more. I write a lot about 2FA on my site, All Things Auth [1], and do teardowns of 2FA implementations for sites.
In March, we featured Zapier [2] in a screencast episode and a 5 post series digging deep into their 2FA implementation and related topics. I highlighted some things they are doing well and also made suggestions on how they could improve.
I plan to continue doing teardowns for 2FA implementations from many different types of sites. I plan to create a definitive guide to aggregate 2FA implementation best practices.
Whoops! Good catch. Fixed.
That is a great idea! I am 100% in favor of helping the users understand the security tradeoffs between the 2FA methods.
We definitely have it on the roadmap to update 2FA Notifier to include more educational content. Thanks for the feedback!
I am currently writing a series on 2FA on my site All Things Auth [1] that gets into the details explaining how each method works and exploring the security and usability tradeoffs of each. I want to put together a summary and/or infographic highlighting the main takeaways and hopefully like to something like that from 2FA Notifier.
Currently, we use the data from twofactorauth.org [2] as our main data feed. I definitely encourage you to check out their community on GitHub and propose your idea there too!
I submitted 2FA Notifier to the FF store and got approved, but it still stuck in "Awaiting Review" state. This is my first time working with the FF store, so figuring things out as I go. If you've got any tips/resources/etc that might be helpful, shoot them my way!
I'll post here again once the extension is available to install via the FF store.
Thanks for the feedback! We use the data from twofactorauth.org as our main data feed, so that is where we pick up the domains.
I am definitely open to augmenting those entries, but trying to think about ways to either automate (ideal) or crowdsource contributions on the data side.
Any thoughts? Would you be interested in contributing data updates like this?
I am in the process of getting into the FF store as we speak! Stay tuned!
Hey everyone! I created 2FA Notifier with my friend, Ray.
We noticed that many people enable 2FA after they realize the services they already use support it! So, we made 2FA Notifier [1], an open source web extension that notifies you when sites you visit support 2FA. Anytime you visit a site that supports 2FA, you'll get a notification. Click it to go straight to the docs that explain how to enable 2FA!
Let me know if you take it for a spin! Any and all feedback is helpful to improve the functionality and UX.
Shout with questions and I'll do my best to answer!
I just finished reading Oathbringer by Brandon Sanderson. It is the third book in the Stormlight Archive series. It was a fantastic read and the entire series is totally epic. Sanderson has many different trilogies, novels, and short stories in a universe he calls The Cosmere. If you like fantasy and haven't read any Sanderson, you should definitely check his stuff out!
https://brandonsanderson.com/books/the-stormlight-archive/oa...
Ready Player One is a super fun read and they are making it into a movie too!
After rereading my initial comment and the responses to it, I absolutely agree that my tone was unduly harsh and condescending. I did not at all intend that when I wrote the comment, but it was clearly the result regardless. I apologize to everyone in this thread for not communicating my concerns more constructively. I have tried to reply to each comment in a much more constructive way.
----------------------- > Heh, every company I have worked for, I have had to share passwords to tools in some form or the other - private keys, certificate files, shared account passwords to name a few.
See my comment acknowledging that I was flat out wrong to argue that users never have a need to share passwords: https://news.ycombinator.com/item?id=15996129.
As a developer needing to share passwords, there are plenty of secure ways to achieve sharing passwords without resorting to using email. For example, Hashicorp Vault [1] is a free and secure option which has gained lots of traction in the marketplace in recent years.
So, you are willing to "vouch" for some random closed source software without every seeing the code and yet here you vilify code that is open.
It is quite widely accepted that password managers are the best practice for sharing passwords. The SecurityPlanner project recommends LastPass [2], has some very well respected folks from the security community on their advisory and peer review boards [3], including Bruce Schneier, Gary Belvin, and Iulia Ion. Also, the EFF recommends using a password manager [4]. Troy Hunt has an article explaining and recommending password managers (e.g. 1password) [9].
Also, most of the mainstream commercial password managers publish white papers on their security architecture and often undergo pen tests, security audits, etc. For example, see [5] [6] [7] [8].
Password managers utilize end to end encryption by encrypting the password on your device before sending it to their servers (for syncing between devices, etc). Without seeing the source code, you can observe the traffic over the wire to prove that these password managers are implementing end to end encryption and only sending cipher text over the wire to the remote server. In contrast, the Pass.sh service sends plain text passwords over the wire to their servers, which means that their servers have access to the plain text password.
[1] https://www.vaultproject.io/ [2] https://securityplanner.org/#/tool/password-manager [3] https://securityplanner.org/#/who-we-are [4] https://ssd.eff.org/en/node/23/ [5] https://lastpass.com/enterprise/security [6] https://support.1password.com/security-assessments/ [7] https://keepersecurity.com/security.html [8] https://www.dashlane.com/download/Dashlane_SecurityWhitePape... [9] https://www.troyhunt.com/only-secure-password-is-one-you-can...
After rereading my initial comment and the responses to it, I absolutely agree that my tone was unduly harsh and condescending. I did not at all intend that when I wrote the comment, but it was clearly the result regardless. I apologize to everyone in this thread for not communicating my concerns more constructively. I have tried to reply to each comment in a much more constructive way.
-----------------------
As far as sharing passwords, I was flat out wrong to argue that users do not need to share passwords. As you point out, users may need to share passwords because of the shortcomings in any given software because they might not have an option to switch to a different solution. As part of educating users about best practices, many courses educate users to not share their password with corporate IT/support desks/bosses/coworkers/etc. I think that is the absolute correct thing to teach to users so that the initial reaction to any request to share a password is suspicion and hesitation. In the event that users DO have a legitimate reason to share passwords, they should use a tool which implements end to end encryption so that only the intended recipient can read the plain text password. As you also highlight, most password managers provide some ability to do just that.
The LastPass article that you linked to highlights the fact that, although there are reasons to share passwords, users should do so securely:
You don’t have to rely on insecure methods of sharing passwords, like through email, texting, or writing them down.
As far as the ephemerality of Pass.sh links, you are absolutely correct that I neglected to consider that security benefit. I absolutely agree that the ephemerality of messages on Pass.sh means that it is more secure to send a password using Pass.sh than via normal email. However, this is missing the point. Just because A is better than B does not mean that A is good. Sending passwords via plain email and by Pass.sh link in an email are both insecure methods of sharing passwords and end users should avoid them both. Instead, they should use one of the many tools (e.g. password managers) which solve the problem of sharing passwords with other people in a significantly more secure way (e.g. end to end encryption). They could even use a free solution like Signal [2] which provides end to end encryption. Yes, the password will stay in the receiver’s message thread forever, but you have to trust the receiver to send them a password via any channel in the first place.
I realize that users will continue to follow some bad habits in terms of security regardless of my comments here in HN. However, I think one critical component of solving the larger problem is education and developers play a role in that education. When we build solutions that we claim are secure, we should be upfront about explaining how they work, the appropriate use-cases the tool is trying to solve, and the potential risks associated with using the tool. Developers are in a unique position to answer those questions and normal non-technical users are often not aware of the questions they should even be asking in the first place.
After rereading my initial comment and the responses to it, I absolutely agree that my tone was unduly harsh and condescending. I did not at all intend that when I wrote the comment, but it was clearly the result regardless. I apologize to everyone in this thread for not communicating my concerns more constructively. I have tried to reply to each comment in a much more constructive way.
-----------------------
Creating a secure connection between the browser and your server using TLS is clearly important, but does not provide end to end encryption.
First, let’s agree on the definition of end to end encryption.
On Wikipedia article [1]: > End-to-end encryption (E2EE) is a system of communication where only the communicating users can read the messages. In principle, it prevents potential eavesdroppers – including telecom providers, Internet providers, and even the provider of the communication service – from being able to access the cryptographic keys needed to decrypt the conversation
On the Signal homepage [2]: > Signal messages and calls are always end-to-end encrypted and painstakingly engineered to keep your communication safe. We can't read your messages or see your calls, and no one else can either.
End to end encryption means that the contents of a message is encrypted by a sender before it leaves the sender’s device and can ONLY be decrypted by the intended receiver. The application servers, communication channel, unintended recipients, etc all do not have the ability to read the plain text content of the message.
In the context of the Pass.sh application, there are three (3) parties: the user who wants to send a password to someone (“the sender”), the Pass.sh application servers (“the servers”), and the user who the sender wants to send the password to (“the receiver”). This is the data flow for the Pass.sh application:
1. the sender enters some plain text content into the text box on the website 2. the plain text content is sent to the servers via a secure TLS connection 3. After resolving TLS on the servers, the plain text is available to the application, where it is encrypted and stored in a database. 4. The application presents a link to access the plain text to the sender. 5. The sender emails the link to the recipient. 6. The receiver reads the email and clicks on link. 7. Without authenticating, the receiver is shown the plain text.
In order for this to be end to end encryption, only the sender and the receiver should be able to read the plain text password. However, since the Pass.sh servers can also read the plain text content, this solution, by definition, does not use end to end encryption.
In step #3, the plain text is available to the servers, which means that it is also available to a huge range of potential parties: whomever is running the servers, application audit logs, any front end proxies that might be in use (e.g. Cloudflare, AWS, etc), a third party metrics or logging service that the servers might be using, or the servers could be flat out malicious and send the plain text off to someone collecting passwords for nefarious use. All of these are completely transparent to the user, so the password could be compromised even if the sender and the receiver both observe the “correct” behavior; they have zero guarantees that the password has not been compromised as soon as it is sent to the servers.
It would be a huge improvement to the security UX if the Pass.sh homepage made it clear to users that the servers can read the plain text password that they enter into the input box. Also, it would likely help users if Pass.sh provided much more written explanation about the use-cases that it believes Pass.sh can securely address.
---------------
Response to potential questions/comments:
“Well, okay, we might have the plain text password in step #3, but we don’t know the username, so it’s fine”.
Correct, you only have the password, but that is already a huge problem. For example, hackers could easily cross reference the provided plain text password against previously obtained data breaches from other services to check for positive hits. Users reuse passwords all the time (even though they shouldn’t) and the chance of getting a positive hit on a user provided password is likely much higher than brute forcing.
“Well, the code is open source, so I know that it is not doing anything malicious and can be trusted.”
Assuming that we agree that end users cannot trust versions of Pass.sh which are hosted by an unknown party because they cannot guarantee which code is actually powering the service, the argument could be made that Pass.sh is safe if you run the software yourself because it is open source and you can review the software. Of course, if you review the application code yourself and are confident in the security of the service, that is an improvement for you as a developer. However, this will only increase the trust level for users who know for a fact that you are trustworthy and are hosting the version of Pass.sh with which they are interacting.
The Pass.sh service is publicly available on the internet for anyone to use and claims on the homepage that it is “Secure Password Sharing Service”. End users cannot trust that the publicly available version is secure because they cannot guarantee that the code powering that service matches the open source code available for review. If the users could verify that the end to end encryption was taking place on their device before any data was sent over the wire, that would drastically reduce this risk. This is the main reason that I think the Pass.sh project would better serve end-users by not providing a publicly hosted version and instead instead targeting developers who have the ability to audit the software themselves to run it if they believe that it solves a problem for them or their organization.
“Using Pass.sh is good because it is more secure than sending a password via normal email, which is what users are doing right now, because the password is deleted after X time or Y views.”
I absolutely agree that the ephemerality of messages on Pass.sh means that it is more secure to send a password using Pass.sh than via normal email. However, this is missing the point. Just because A is better than B does not mean that A is good. Sending passwords via plain email and by Pass.sh link in an email are both insecure methods of sharing passwords and end users should avoid them both. Instead, they should use one of the many tools (e.g. password managers) which solve the problem of sharing passwords with other people in a significantly more secure way (e.g. end to end encryption). They could even use a free solution like Signal [2] which provides end to end encryption. Yes, the password will stay in the receiver’s message thread forever, but you have to trust the receiver to send them a password via any channel in the first place.
------------
Security UX
The home page has the text “go ahead, i'm not looking…” on it. While this might be intended as cheeky marketing talk, to me this presents a lack of seriousness and trust. First, as covered above in detail, the Pass.sh servers are in fact looking because they can see the plain text of the password. Second, normal non-technical users may read that text and believe that Pass.sh truly cannot look at their password. This is setting up a false sense of security that normal non-technical users likely do not understand the risks they are taking.
It would be great if Pass.sh provided an explanation of the security architecture for users to review. This would help people understand how the service functions and they could make a more informed decision whether it met their needs or not. Currently, someone would need to either have a technical background and/or audit the code in order to get even an overview of how the service works.
[1] https://en.wikipedia.org/wiki/End-to-end_encryption [2] https://signal.org/
Troy Hunt just published and article today (Dec 19th) titled "Fixing Data Breaches Part 2: Data Ownership & Minimisation" , which discusses this exact topic [1]. The entire post is worth a read, but he offers an excellent summary:
Summary This whole post is about giving control of data back to the rightful owners and minimising the impact on them when a breach occurs. This is equal parts a fundamentally simple objective to achieve and one that is enormously difficult. It's simple not to request that someone provides their date of birth to a cat forum; neither the site nor the user themselves lose anything by not collecting this data. Yet it remains a difficult objective because not only do so many services continue to view our data as an asset, they never expect to be the victim of a data breach which then turns that data into a liability.
[1] https://www.troyhunt.com/fixing-data-breaches-part-2-data-ow...
One thing that drastically simplified my life and removed an incredible amount of stress was getting rid of my car. Since graduating college in 2010, I have moved apartments ~13 times and lived in 4 different cities (Baltimore, D.C., Denver, Breckenridge, and ~NYC). Initially, I needed a car to drive to work, but then I got a new job which allowed me to walk to work. I still kept my car because it was already paid off, but it was an incredible source of stress for a bunch of reasons:
- What day of the week is it? Do I need to move the car for street cleaning today? (If I get this wrong, I get a parking ticket).
- Did I remember to lock the car and put all of the windows up? (I once thought that all of the windows were up not realizing that one of the back windows was open a few inches and my car was broken into).
- What do I have to do to register my car in this new city? How much will it cost and when can I take an entire day off work to go do it? Can I even complete all of the required steps in one day?
- The car is making a strange sound. I better get it to a mechanic. How do I find a good mechanic? How much will it cost to get it fixed? That feels like a really high price, should I get a second opinion? Where do I find a second mechanic? When am I able to take off work to bring the car to the mechanic?
- I have to fly out of town for work/pleasure. Where do I park my car while I'm gone. Parking at the airport is really expensive, but maybe the best option? Can I leave it parked on the street? What are the parking rules for my neighborhood?
- Car insurance. Am I getting a good deal? Do I have to do anything when I move addresses and/or states? Am I covered if a friend borrows my car? etc, etc
- Costs associated with gas, insurance, maintenance, loan...
I had a huge amount of anxiety from constantly worrying about the cost associated with owning a car and the required time to maintain it. Eventually, my car got old enough that I couldn't justify putting more money into it and I sold it for a nominal amount to CarMax. I should have done it sooner. It was an interesting transition to not owning a car, but was overall incredibly liberating. I had removed an entire source of stress from my life and haven't looked back since. I don't plan to buy another car anytime soon.
To get around now, I rely much more heavily on public transportation, biking, walking, and Lyft/Uber, Car2Go, non-profit carshare programs, etc. I also don't hesitate to rent a car from Enterprise/etc if I need one for an errand, vacation, etc. Being able to give the car back when I'm done with it and literally not having to worry about anything is quite amazing.
Disclaimer: I realize that some people need a car to get to work or for other important reasons. I'm not saying that owning a car is bad or encouraging anyone else to go sell their car to CarMax tonight. I'm just sharing my story about removing a source of stress that I had in my personal life.
@jc_sec, I see that you commented that you're the author of this tool. I am trying to wrap my head around why you created it, but am having a really difficult time understanding the motivation. Perhaps, it was an educational project for yourself to learn about working with crypto. If that was the case, then I applaud your learning, but encourage you to treat such projects as throw away learning experiences and not publish them. In fact, I think that this tool is actually quite dangerous and it would be irresponsible to leave it available online and encourage its use.
First, users should NEVER share their passwords with anyone. Ever. The entire purpose of this tool is to encourage users to share their passwords, which is the exact opposite behavior that any good security training program should be teaching users. Any reason that someone offers to justify the sharing of a password is simply a shortcoming in a specific piece of software supporting business needs. Ironically, Troy Hunt had an article this week about password sharing, which covers the topic well [1][2]. I won't rehash the argument here, but do please read his post.
Second, the tool offers zero security benefit over sending a password via email.
It's better than emailing passwords in plaintext
No it is not.
The content entered into the text box is accessible simply by visiting a link, which means that the data is not end to end encrypted. Any email containing the link is equivalent to containing the password because someone simply needs to click on the link to obtain the password. It doesn't matter which cipher you use, which library you use, where you store the keys, etc because the server running the application has the ability to read the plain text content. This tool does not provide end to end encryption, which is required for any reasonable password management tool.
makes security more accessible to folks who dont have the time/incinlination/technical ability to set up keybase and/or estbalish PKI for sharing secrets.
Again, no it does not. This tool does not offer any security value, so it cannot make security more accessible to users. Users do not need to know how to setup Keybase or PKI in order to use other existing secure tools. For example, users should utilize software specifically built for managing passwords, such as LastPass [3], 1Password [4], Dashlane [5], Keeper [6], or a vetted open source alternative.
I know a thing or two about building end to end encryption systems based on my first hand experience as a Senior Engineer at Virtru [7], a commercially available end to end email encryption solution. I was one of the original employees and helped design the fundamental security architecture, which has been audited by respected independent third parties. You can read more about Virtru's technology on their website [8].
Again, I do not know whether you truly think that this tool is secure, or if you were just trying to educate yourself and develop some new skills working with crypto libraries. Please realize that this feedback is not intended to vilify, but to educate. Please consider taking this tool down and instead promoting a secure alternative to password management to anyone who asks for guidance on sharing passwords.
[1] https://www.troyhunt.com/the-trouble-with-politicians-sharin...
[2] https://www.troyhunt.com/weekly-update-64/
Wouldn't it make even more sense to use the Web Crypto API instead of any JS crypto library loaded from the server?
I have had a very similar idea for a tracking app for a looong time. This is by far the closest I've seen to my idea.
I would definitely use something like this. However, I would primarily want to use a mobile app for daily tracking. It would also be nice to be able to set a daily reminder time for each item I'm tracking so that I remember to fill it in.
Is this just a fun side project, or do you plan to monetize somehow?
Authy desktop is definitely a step in the right direction in terms of UX on desktop. However, I dislike that I still need to manually search for the correct 2FA entry and copy/paste the code into the browser. I mentioned in another comment [1] that I am working on a project called Two Factor Buddy (2FB) that integrates directly with the browser and automates the entry of 2FA codes entirely. IMO, a much more pleasant UX.
Also, I do not like that Authy cloud backup relies on user provided passwords because users are notoriously, insanely, ridiculously bad at creating secure passwords. If an attacker gets ahold of the encrypted secret via Authy's servers, then they can work on brute forcing it locally. IMO, the ideal is to have a simple process to sync 2FA secrets between all of your trusted devices either directly and out of band (no servers used at all), or via the web using pub/priv keys, which would be significantly more secure than a user provided password for encryption. The key is to make sure it is still insanely simple to use, though.