Password is sent in cleartext

hully · 2022-11-14 07:41:40

When you register to the forum, your password is sent in cleartext by email.

Is this secure practice?

GaKu999 · 2022-11-14 09:55:06

hully wrote:

When you register to the forum, your password is sent in cleartext by email.
Is this secure practice?

That password is meant to be changed, so its not that big of a deal.
If for xyz reasons your email is compromised, I doubt that this little forum should be your biggest concern.

hully · 2022-11-14 10:07:59

GaKu999 wrote:

hully wrote:
When you register to the forum, your password is sent in cleartext by email.
Is this secure practice?
That password is meant to be changed, so its not that big of a deal.
If for xyz reasons your email is compromised, I doubt that this little forum should be your biggest concern.

Do you save the password in cleartext in the database?

GaKu999 · 2022-11-14 10:26:50

hully wrote:

GaKu999 wrote:
hully wrote:
When you register to the forum, your password is sent in cleartext by email.
Is this secure practice?
That password is meant to be changed, so its not that big of a deal.
If for xyz reasons your email is compromised, I doubt that this little forum should be your biggest concern.
Do you save the password in cleartext in the database?

Me? I don't manage this forum.

But any sane system should just save a hash of it.

frostschutz · 2022-11-14 11:16:03

fluxbb is open source so you can check

- generates a random password https://github.com/fluxbb/fluxbb/blob/5 … er.php#L84
- mails the random password https://github.com/fluxbb/fluxbb/blob/5 … r.php#L251
- database stores it as a hash https://github.com/fluxbb/fluxbb/blob/5 … #L160-L163

hully · 2022-11-14 13:55:41

oh ok. Thanks

schard · 2022-11-14 16:29:05

hully wrote:

When you register to the forum, your password is sent in cleartext by email.
Is this secure practice?

No, it is not. The password is send through an insecure channel (SMTP) to you.
You should immediately regard it as compromised and change it (what @GaKu999 already suggested).
The issue is that FluxBB is abandonware from the last decade and nobody cares to upgrade to a maintained forum platform that adheres to modern security standards.

Trilby · 2022-11-14 16:40:54

What is a better approach? The goal is to confirm the email address, and there isn't really any other approach then sending a key in an email.

progandy · 2022-11-14 17:08:43

Trilby wrote:

What is a better approach? The goal is to confirm the email address, and there isn't really any other approach then sending a key in an email.

You can let the user set the password during registration and use a separate e-mail verification token.

By the way, the most recent public discussion about replacing FluxBB is https://gitlab.archlinux.org/archlinux/ … issues/257

Last edited by progandy (2022-11-14 17:19:49)

Trilby · 2022-11-14 17:15:43

And that would be no different. Whether you call it a "password" or a "token" it's the same result: it's one bit of information sent from the server to the user's email in plaintext. Neither one is the credential used to log into the account once the account exists.

progandy · 2022-11-14 17:23:00

Trilby wrote:

And that would be no different. Whether you call it a "password" or a "token" it's the same result: it's one bit of information sent from the server to the user's email in plaintext. Neither one is the credential used to log into the account once the account exists.

The difference would have been that in the short timeframe between registration and password change your account is safe from an attacker that can read your mail. You are right that it doesn't matter, though. Anyone able to read the mails can use the password reset function.

Trilby · 2022-11-14 17:29:23

No it is incorrect to say that even for that short time "your account is safe." An account is safe, but not yours. A server-generated empty account with absolutely no personal nor identifying information is kept safe.

If someone intercepts this initial email, they can log in to the account you intended to create but hadn't yet. In the worst case it creates a minor hassle when you try to complete the account creation: it will fail, and you'd need to request a new token/password be sent. And either only you will get this, or you and the attacker will get it and you'll be in the same spot again. At no point is any user data compromised as there is absolutely no user data in existence at that point.

This is the difference between a theif breaking into a hospital and stealing patient records and a theif breaking into the supply room and stealing empty manilla folders that had not yet been used for any patient. The former is an information security problem, the latter is not. Just because they stole the folder that may have been intended to hold private data later on, it doesn't yet. It's a nusiance (a loss of office supplies) but not a threat to user data.

In theory the attacker could "vandalize" the account a bit. But again this would be prior to the intended user ever even getting access to it. The intended user would attempt to log in and it would fail, they might reset the password, then when they finally log in they see the attacker put some like to a random adult website in the signature field of the profile, or posted some garbage on the forum already. This is akin to the hospital theif smearing excrement on the folders and leaving them in the supply room: when it's time to create a new patient record, these soiled folders would come out and one could decide "do I use this poo-smeared folder as-is, clean it off, or do I go get a fresh one." It's an annoyance, but a simple decision... and not a privacy / security issue.

All login mechanisms require something (whether you call it a password, or token, or anything else) to be shared to initate the interaction. In theory, the forums could require each user to have a key pair and post their public key to the account creation form. This would then be used to encrypt a password or whole email to them which only they could decrypt with their private key. While theoretically quite doable, it'd be a bit of hassle for many users who don't already have key pairs, and it would all be in the name of protecting something that requires absolutely no protection (I don't mean to imply that forum accounts are not that important, but quite literally, at that point in the exchange there is nothing in the account at all).

Last edited by Trilby (2022-11-14 17:45:05)

schard · 2022-11-14 19:24:21

Trilby wrote:

And that would be no different. Whether you call it a "password" or a "token" it's the same result: it's one bit of information sent from the server to the user's email in plaintext. Neither one is the credential used to log into the account once the account exists.

Nope. Thanks to HTTPS a password entered upon user registration is sent through a secure channel (that is HTTPS) to the backend server where it is immediately hashed and stored.

Edit: Sorry, didn't read the email verification part. Yes, this is an issue. I'd have too think about that, but it's late here now and I'm tired.

Edit2: You can send the user an email verification token, that they must enter *when they are logged in*.
This way an attacker that gets hold of the token, can't use it, since they don't know the user's password they'd need to login to their account in order to enter the token.
And the password was entered by the user upon registration and sent via HTTPS to the server backend only, where it got Argon2id hashed and stored. Problem solved.

Last edited by schard (2022-11-14 19:31:40)

twelveeighty · 2022-11-14 19:50:23

Sending passwords via email isn't secure, but imo 'good enough' for a site like the Arch forums, especially if you change it immediately afterwards. Now, if the user changes it to a password that's easy to guess or (even worse) you are using also on multiple different sites, that's definitely not 'good enough', but that's behavior I don't think should be the forum's responsibility.

Password re-use is (I believe) the #1 reason criminals would be trying to gain access to the Arch forums' (hashed) passwords, not to start ghost-writing Newbie Corner responses on Trilby's account

ewaller · 2022-11-14 21:40:04

twelveeighty wrote:

not to start ghost-writing Newbie Corner responses on Trilby's account

Interesting thought.

My take; there are all manner of ways to tighten this up, but this is not a banking site, or a medical site.
For a new user, job one should be to change the password.

As a moderator, I prefer the simple approach we use as I don't have to spend too much time helping new users get established. If only hotmail would deliver our mail...

jasonwryan · 2022-11-14 21:48:02

ewaller wrote:

If only hotmail would deliver our mail...

To be fair, anyone with a Hotmail account has no business posting here.

Trilby · 2022-11-14 22:32:01

schard wrote:

Edit2: You can send the user an email verification token, that they must enter *when they are logged in*.

This would allow *anyone* to block another email address from registering. I could attempt to create an account with someone else's email (before they did) such as schard@yourdomain.com and create a password that the database would then store (a hashed version of) associated with that email. It would send a token to schard@yourdomain.com, but that token would be useless to the recipient as they weren't the one who created the account and they don't know the password. So now an attacker doesn't even need to read your email, as long as they know your email address they can throw in a wrench that could prevent you from registering at all.

Really, the current system *is* secure. Call the first thing that is sent to a user a "token" instead of a "password" and you have Schard's proposed system with the exception that an attacker can't block legit registrations. The user provides their email but doesn't create a password yet. The website sends them a token to verify their email. When they verify their email by entering that token on the site, they then create a user password (sent via https). Sounds secure, right? So what's wrong with reusing a single field in the database for both the "token" and the "password" given that these two values will never both be needed simultaneously in the life-cycle of an account?

schard · 2022-11-14 23:47:42

True. I did not think of the DOS scenario. But such email verifications usually have a timeout, so you would need to re-register the foreign email periodically.

Allan · 2022-11-14 23:58:36

jasonwryan wrote:

ewaller wrote:
If only hotmail would deliver our mail...
To be fair, anyone with a Hotmail account has no business posting here.

My Arch Linux email address is a forward to a hotmail account

jasonwryan · 2022-11-15 00:06:00

Allan wrote:

jasonwryan wrote:
ewaller wrote:
If only hotmail would deliver our mail...
To be fair, anyone with a Hotmail account has no business posting here.
My Arch Linux email address is a forward to a hotmail account

QED!

Arch Linux

#1 2022-11-14 07:41:40

Password is sent in cleartext

#2 2022-11-14 09:55:06

Re: Password is sent in cleartext

#3 2022-11-14 10:07:59

Re: Password is sent in cleartext

#4 2022-11-14 10:26:50

Re: Password is sent in cleartext

#5 2022-11-14 11:16:03

Re: Password is sent in cleartext

#6 2022-11-14 13:55:41

Re: Password is sent in cleartext

#7 2022-11-14 16:29:05

Re: Password is sent in cleartext

#8 2022-11-14 16:40:54

Re: Password is sent in cleartext

#9 2022-11-14 17:08:43

Re: Password is sent in cleartext

#10 2022-11-14 17:15:43

Re: Password is sent in cleartext

#11 2022-11-14 17:23:00

Re: Password is sent in cleartext

#12 2022-11-14 17:29:23

Re: Password is sent in cleartext

#13 2022-11-14 19:24:21

Re: Password is sent in cleartext

#14 2022-11-14 19:50:23

Re: Password is sent in cleartext

#15 2022-11-14 21:40:04

Re: Password is sent in cleartext

#16 2022-11-14 21:48:02

Re: Password is sent in cleartext

#17 2022-11-14 22:32:01

Re: Password is sent in cleartext

#18 2022-11-14 23:47:42

Re: Password is sent in cleartext

#19 2022-11-14 23:58:36

Re: Password is sent in cleartext

#20 2022-11-15 00:06:00

Re: Password is sent in cleartext

Board footer