Password Changing Policy
-
As of now we will be implementing a new policy for password changes, this has been an ongoing issue.
When can I request a change?
Switch Users are eligible for a change anytime. Their password will only be changed if they use the registered IP address that was used upon their account creation or the last IP used after you were logged in. Create an alt accountDesktop/Tablet/Smartphone Users are required to have an email registered depending on the circumstances. You will be able to request a password change without email twice. Like Switch users, you must use the last logged in IP or the IP used upon your account creation. Remember to create an alt account or DM a Global Mod on the BDNS Discord
If at anytime you do not receive the password change email (which works), you should email contact@browsedns.net! We will ask you to upload your IP using a reliable IP grabber like whatismyip.com, after verification is complete you will be able to change your password.
@Global-Moderators
@Administrators
Regards,
BDNS Forum Administration -
using ip addresses for authentication is extremely risky, even if switch users may not be able to easily access email. ill label a few reasons.
(1.) often, residential ip addresses are dynamic, so theyll change often. this can prevent someone from authenticating.
(2.) when a user requests a password change via email and doesnt receive an email, they are encouraged to contact bdns and submit their ip address. what if an attacker ip logs a user to take over their account? will the sender email address be verified, and what if the user registered with an email address they can no longer access? how will any of this be verified?
(3.) user accounts could be stolen if an attacker on a local network impersonates them.
while the attack scenarios can be considered edge cases, they still need to be considered, especially in a forum this large. someone is bound to run into one of these issues eventually.instead of ip authentication, i suggest any of the following:
- knowledge based authentication. such as having multiple security questions that the user creates upon registration.
- access based authentication. force users to register with email addresses. for switch users, provide suggestions on email providers that are minimal and work with low resource consumption.
i dont mean to complain or whine about this password reset policy, im just concerned it could backfire and cause future issues.
she/her, 16, maple is teh best
-
using ip addresses for authentication is extremely risky, even if switch users may not be able to easily access email. ill label a few reasons.
(1.) often, residential ip addresses are dynamic, so theyll change often. this can prevent someone from authenticating.
(2.) when a user requests a password change via email and doesnt receive an email, they are encouraged to contact bdns and submit their ip address. what if an attacker ip logs a user to take over their account? will the sender email address be verified, and what if the user registered with an email address they can no longer access? how will any of this be verified?
(3.) user accounts could be stolen if an attacker on a local network impersonates them.
while the attack scenarios can be considered edge cases, they still need to be considered, especially in a forum this large. someone is bound to run into one of these issues eventually.instead of ip authentication, i suggest any of the following:
- knowledge based authentication. such as having multiple security questions that the user creates upon registration.
- access based authentication. force users to register with email addresses. for switch users, provide suggestions on email providers that are minimal and work with low resource consumption.
i dont mean to complain or whine about this password reset policy, im just concerned it could backfire and cause future issues.
@maple recently, someone was catfishing me on here pretending to be a staff on here....
the hacker thing is actually pretty real.
(side note, that is why i have the no edating thing on my signature bc uh.... i just found that experience unpleasant af) -
using ip addresses for authentication is extremely risky, even if switch users may not be able to easily access email. ill label a few reasons.
(1.) often, residential ip addresses are dynamic, so theyll change often. this can prevent someone from authenticating.
(2.) when a user requests a password change via email and doesnt receive an email, they are encouraged to contact bdns and submit their ip address. what if an attacker ip logs a user to take over their account? will the sender email address be verified, and what if the user registered with an email address they can no longer access? how will any of this be verified?
(3.) user accounts could be stolen if an attacker on a local network impersonates them.
while the attack scenarios can be considered edge cases, they still need to be considered, especially in a forum this large. someone is bound to run into one of these issues eventually.instead of ip authentication, i suggest any of the following:
- knowledge based authentication. such as having multiple security questions that the user creates upon registration.
- access based authentication. force users to register with email addresses. for switch users, provide suggestions on email providers that are minimal and work with low resource consumption.
i dont mean to complain or whine about this password reset policy, im just concerned it could backfire and cause future issues.
@maple the staff they were impersonating thankfuly wasn't hacked tho. it was probably a kid, but the hacking issue is a very real concern
-
using ip addresses for authentication is extremely risky, even if switch users may not be able to easily access email. ill label a few reasons.
(1.) often, residential ip addresses are dynamic, so theyll change often. this can prevent someone from authenticating.
(2.) when a user requests a password change via email and doesnt receive an email, they are encouraged to contact bdns and submit their ip address. what if an attacker ip logs a user to take over their account? will the sender email address be verified, and what if the user registered with an email address they can no longer access? how will any of this be verified?
(3.) user accounts could be stolen if an attacker on a local network impersonates them.
while the attack scenarios can be considered edge cases, they still need to be considered, especially in a forum this large. someone is bound to run into one of these issues eventually.instead of ip authentication, i suggest any of the following:
- knowledge based authentication. such as having multiple security questions that the user creates upon registration.
- access based authentication. force users to register with email addresses. for switch users, provide suggestions on email providers that are minimal and work with low resource consumption.
i dont mean to complain or whine about this password reset policy, im just concerned it could backfire and cause future issues.
@maple said in Password Changing Policy:
using ip addresses for authentication is extremely risky, even if switch users may not be able to easily access email. ill label a few reasons.
(1.) often, residential ip addresses are dynamic, so theyll change often. this can prevent someone from authenticating.
(2.) when a user requests a password change via email and doesnt receive an email, they are encouraged to contact bdns and submit their ip address. what if an attacker ip logs a user to take over their account? will the sender email address be verified, and what if the user registered with an email address they can no longer access? how will any of this be verified?
(3.) user accounts could be stolen if an attacker on a local network impersonates them.
while the attack scenarios can be considered edge cases, they still need to be considered, especially in a forum this large. someone is bound to run into one of these issues eventually.instead of ip authentication, i suggest any of the following:
- knowledge based authentication. such as having multiple security questions that the user creates upon registration.
- access based authentication. force users to register with email addresses. for switch users, provide suggestions on email providers that are minimal and work with low resource consumption.
i dont mean to complain or whine about this password reset policy, im just concerned it could backfire and cause future issues.
Thanks for the post.
If you are locked out of the email that is connected to your account, unfortunately there is nothing we can do and you'd be forced to make a new account. I do believe that with dynamic IP changes, we could always look for IP address details, if they do not match then you'll see the same result.
All I will say is I do have a few tricks up my sleeve so I am well aware of the security risks that come from this. If your account is hacked that is a completely different street, typically once we receive a message (or) email that the account is hacked we would begin with ip address information and obviously the rest of the verification things that I will keep strictly for myself and for Maribitt to hear.
The administrators are likely to provide other verification steps as they control our contact emails, this is just a start of what you'd be asked.
I would be looking for users with emails to use 2 step authentication...
I do not believe this hacking situation is a problem as of now. However, I will also look at the administrators guidance on this as it is a very tricky and serious thing to try to fix.
I'm positive our backend is tough to hack into, same with the accounts and the administrators are always quick to respond to these situations.
All reports of hacked accounts are taken seriously, first we will ban the account and leave it up to the administrators to handle.
Catfishing is completely unrelated and I highly doubt we'd have an issue when it comes to password changes. This is why it is extremely important to use emails and use 2 Step Authentication on your emails that are connected to your account!
I have not really talked about these hacking problems you all have stated and we have never encountered these issues.
We could do somekind of co-account thing so you could registered it as a backup account and we'd take note of it, that way it would be completely private and a safe way to do this.
Edit: To be clear, I will look for email services for Switch users to use when I get home from work.
-
The only email service that works on switch that I know of is
outlook.com/login(BROWSER IS NOT SUPPORTED ANYMORE)Green: Online
Yellow: Busy or Studying
Red: DNI please.
Gray: Offline or lurking
SB-4717-1413-8119 -
The only email service that works on switch that I know of is
outlook.com/login(BROWSER IS NOT SUPPORTED ANYMORE) -
@Ameris_Blizz I used to use that, it stopped working the last couple of times I've tried using it
@YourAriesBestie Awh, the browser isn't supported anymore :c
-
To add on to what Raven said, we have a few other DNS related tools for verifying Switch browser user identities to determine their device/request without needing to trust them directly. That being said, it's still a sensitive area, and it'd be great if users can provide a reliable email account to us. If that's not an option, and we aren't able to verify them another way, then creating an alternate (or new) account is really the only option.
And of course, if there's evidence of widespread account reset related issues, we'll act quickly on it. If someone messaged you pretending to be a staff member, please flag the user, and report it to moderators or admins immediately.
List of legitimate staff accounts: https://browsedns.net/topic/10407/browsedns-staff-list
-
@maple said in Password Changing Policy:
using ip addresses for authentication is extremely risky, even if switch users may not be able to easily access email. ill label a few reasons.
(1.) often, residential ip addresses are dynamic, so theyll change often. this can prevent someone from authenticating.
(2.) when a user requests a password change via email and doesnt receive an email, they are encouraged to contact bdns and submit their ip address. what if an attacker ip logs a user to take over their account? will the sender email address be verified, and what if the user registered with an email address they can no longer access? how will any of this be verified?
(3.) user accounts could be stolen if an attacker on a local network impersonates them.
while the attack scenarios can be considered edge cases, they still need to be considered, especially in a forum this large. someone is bound to run into one of these issues eventually.instead of ip authentication, i suggest any of the following:
- knowledge based authentication. such as having multiple security questions that the user creates upon registration.
- access based authentication. force users to register with email addresses. for switch users, provide suggestions on email providers that are minimal and work with low resource consumption.
i dont mean to complain or whine about this password reset policy, im just concerned it could backfire and cause future issues.
Thanks for the post.
If you are locked out of the email that is connected to your account, unfortunately there is nothing we can do and you'd be forced to make a new account. I do believe that with dynamic IP changes, we could always look for IP address details, if they do not match then you'll see the same result.
All I will say is I do have a few tricks up my sleeve so I am well aware of the security risks that come from this. If your account is hacked that is a completely different street, typically once we receive a message (or) email that the account is hacked we would begin with ip address information and obviously the rest of the verification things that I will keep strictly for myself and for Maribitt to hear.
The administrators are likely to provide other verification steps as they control our contact emails, this is just a start of what you'd be asked.
I would be looking for users with emails to use 2 step authentication...
I do not believe this hacking situation is a problem as of now. However, I will also look at the administrators guidance on this as it is a very tricky and serious thing to try to fix.
I'm positive our backend is tough to hack into, same with the accounts and the administrators are always quick to respond to these situations.
All reports of hacked accounts are taken seriously, first we will ban the account and leave it up to the administrators to handle.
Catfishing is completely unrelated and I highly doubt we'd have an issue when it comes to password changes. This is why it is extremely important to use emails and use 2 Step Authentication on your emails that are connected to your account!
I have not really talked about these hacking problems you all have stated and we have never encountered these issues.
We could do somekind of co-account thing so you could registered it as a backup account and we'd take note of it, that way it would be completely private and a safe way to do this.
Edit: To be clear, I will look for email services for Switch users to use when I get home from work.
@Maditalian i see, thanks for clearing it up. i do a lot of cybersecurity research and it just concerns me seeing policies that could be abused.
in my experience, security through obscurity isnt very effective. if its public, its open to more skepticism and analysis, showing flaws and how to fix it. keeping verification methods secret may not be a good idea. it can also increase user's confidence and trust in the administration to see how their accounts will be kept safe.
im sure the backend is secure, but potential for abuse arises with policies like these. its the user's responsibility to keep themselves safe, but its the forum's responsibility to maintain reliable and secure policies and procedures. this policy isnt 100% reliable and its questionably secure, especially without transparency as to how exactly password reset requests are verified.
overall, i dont quite understand keeping this current system, when its far safer to use knowledge based authentication for user's to reset passwords. it wouldnt even be necessary to implement a co-account system, as all the user needs to do is answer a few security questions.
-
R Raven locked this topic on
