Puri.sm’s “forgot password” function confirms invalid username/emails...?!

I find it odd that the website of such a privacy-focused company allows this:

When invalid usernames or emails are entered during Puri.sm’s Reset Password process, the person making the attempt is informed that “no account exists” for that login.

May I suggest instead, “If an account exists under that name, an email has sent to reset the password”?

I know people — coworkers for instance — that have a high likelihood of being a Purism customer or forum member.

Why should a snooper who knows the email address or even favorite username of such a person be allowed to rule out — or confirm — the existence of an account under that identity?

Note: I am a novice privacy enthusiast, and new to this forum. I am already impressed with some of the well-informed, thoughtful, and unexpected responses to my posts. I look forward to an interesting discussion.


Privacy, yay.


There’s a difference between “private” and “anonymous.”

“Private” means “no one knows what you’re doing.”

“Anonymous” means “no one knows who is doing a given thing.”

So for examples, people at the office know who I am but not what I do at home (privacy). People at the grocery store know what I’m doing but not who I am (anonymity).

Purism is a company focused on privacy versus anonymity, so while they may in a round about way confirm that an account exists (which would probably happen if one were to set up an account that already exists anyway, otherwise there’s some ambiguous error message that wouldn’t make a lot of sense to an honest user), they will not allow access to that account because it’s private.

1 Like

Well, I’m not sure that is exactly the point, and I do know the difference, but Privacy and Anonymity are very closely linked. When either one is compromised, the other may be by default, or at least it is easier for it to be. And both are linked to Security, and to Identity. (P.A.S.I. ?)

I do realize these are not interchangeable terms, but all four are important terms, and interrelated in a way that confusing them can cause one to fudge and trip while trying to practice or explain them.

I mean, Purism does not use its particular laptop password technology merely to keep people from “knowing what you are doing,” but to respect your wish for anonymity, so your identity is not detected, and the knowledge thereof not used to hack through the security… on your laptop… and find out what you are doing. Whoops.

You are probably paraphrasing the terms’ meanings, but the answer does not address the question.

So now I’m even more concerned. A company focusing on privacy is (to follow your thinking) not following best password practices, but fails to do so because it is getting oddly technical in the use of the word ‘privacy’ to the extent that they disregard related best practices of anonymity, security and identify protection. “We are privacy focused, why are you asking us about anonymity?” (I do not actually think they believe this, but perhaps you would like to convince me otherwise lol.)

And though the error message might not make sense to some, it is not ambiguous in the least, nor does understanding it in the way I am describing infer that the understander-er is less than honest. Ask a CEH.

Purism is not disallowing access to your account for purely philosophical or ethical reasons of privacy, I assure you.

Oh dear, I’ve opened a can of worms.

I think this is an important question – specifically, Purism’s error message – and I hope it is addressed.

Maybe just fix it first (wouldn’t do any harm) and then study the risk (might do some good, or some bad by not) and change their lockout system if warranted.

Come to think of it, if an attempt to log into a Puri.sm account fails, or a password is changed, is the account owner alerted? (Would someone please help me catch those two worms?)

Privacy, yay.

If I’m reading your concern correctly, an attacker could find out if an account exists by trying to reset the password which would email the target, and are notified that an account doesn’t exist instead of being told the password reset email has been sent when an account doesn’t exist.

This same attacker could instead try to create an account and find out a username/password is already in use (as @Gavaudan mentioned) and this would not notify the target.

Obscuring whether or not an account exists via password reset request is security by obscurity and in turn not security at all. The only thing accomplished is frustrating a user that typo’s their username/email and thinks a password reset was sent when it wasn’t.

I think the anonymity vs privacy conversation is better suited for its own thread as that is a very in depth and sprawling conversation and this particular detail (password reset concern) would likely get lost and overshadowed. Just a thought.


Which is where the true strength of federated services lies. If you don’t want to share any of your information - create your own instance with disabled registration and you disclose only what you want to disclose to external world.

1 Like

I don’t think this is quite relevant in the context of puri.sm forum nor puri.sm customer accounts for hardware purchases. Pretty sure neither of these are federated nor should be.

Librem.one, sure but the OP didn’t reference librem.one but rather puri.sm

Oh yes, that changes everything, of course federation is sh*t because forums are not federated.

Interesting choice of words to put in his/her mouth. Can’t really see where you inferred all that, all that was said was that “federation” isn’t relevant to this discussion.

1 Like

That was how I interpreted it.

Since you can create an unlimited number of short term or throwaway email addresses, it isn’t a massive issue.

I know many web sites that work the way the OP implies it should, so I can see why the issue is mentioned.

Knowing that an account does not exist is not that big a deal. Knowing that an account does exist is minor privacy fail but it comes at a cost to the would be “intruder” i.e. it could set alarm bells ringing. At the very least Purism should keep enough records for an adequate amount of time so that if it turns out that the password reset was malicious in some way, it can be followed up.

Knowing that an account exists could be a launching pad for either spamming or a brute force attack against the password (since the real account owner probably won’t reset the password if he or she did not initiate it).

As someone who juggles a massive number of email addresses, I find the “fail silently” approach implicitly advocated here at times frustrating.

One approach for this kind of probing is a forced delay i.e. no response either way for X seconds, which at least slows down the intruder.

Password reset is nearly always fundamentally insecure (it’s not secure email, right?) and you would not do it this way at all if more were at stake e.g. internet banking.

I would say that if Purism has intentionally done it this way then this should be stated and I can live with that decision.

Thank you. For a sec I thought I posted on the wrong forum (or site). I think not:

Site Feedback: Discussion about this site, its organization, how it works, and how we can improve it.

I only addressed privacy vs. anonymity because it was in the response, and, for the reasons I stated, missed the point, at least.

So, are Forgot Password protocols (including at puri.sm and purism.one) that confirm the non-existence of an account not less desirable those that only tell the logger-inner to check their email, or — to paraphrase Charlie Manson — am I crazy?

Privacy, yay.

It depends. Desirability is a very vague thing that I cannot quantify.

Is it less secure, no.
Is it less privacy respecting, no.
Is it less convenient, yes. (Only for the target)

Personally, if all other things are equal then less convenient is less desirable. In this case all other things are equal.

And as mentioned, you can try to create an account with the username to find out whether or not an account exists. If you change the password reset behavior would you also then change the account creation behavior so that if you try to create a username that already exists the error message does not tell you this? Doesn’t that make account creation issues exponentially harder on legitimate users with no real impact to an attacker that would just create a legitimate account and search for the user via the myriad of ways to legitimately do that?

For instance if I type @ then start typing a username it attempts to autocomplete legitimate user accounts.

I see no reasonable way to have availability of the service for legitimate users while preventing someone from finding out if a user account exists or not. And I see no reasonable use case where this burden should be on the forum provider.

Thank you for your thoughtful responses.

General concerns, not directed at you:

I do not think that email’s inherit lack of security should relax our expectations for its protection when used, to the contrary — it should prompt us to add what layers we can, imperfect as they may be.

Also, some are too quick to label measures “security through obsurity,” when they may be only intended to misdirect or delay before one’s real security is engaged.

1 Like

And as mentioned, you can try to create an account with the username to find out whether or not an account exists.

Very good point — see, I said I expected an interesting discussion (to me, at least)! Yay.