Is it posible to change your devrant password? If yes where? Cause i cant find it (on phone or desktop)

Reset password?

@ScriptCoded where? Its not under settings or account

log out. and klick forgot password?

@ynnk rather unusual way but i guess it works

@resdac Why offer more than one method of making a change when only one will do? (Despite there being very different contexts between "I want to change my password" and "oops, I forgot my password.")

@powerfulparadox because when you forget your password you rely on a secondary identifier like email whereas with password change you can identify with your previous password. There is a different flow in user interaction

@resdac That's not necessarily true. 2FA can be a thing, even when already logged in. If the option isn't implemented, that's a designer/developer problem, not a nature of interaction problem.

@powerfulparadox 2fa does not enable you to change your password without identification. You can't just jam in your 2fa code and expect a system to recognize you. First you need an indentifier together with your 2fa. This can be either pass or email. But with or without 2fa both flows are still different. For one. Forgot password still relies on you standing outside with enough identification to be let back in. (Like asking a locksmith to change the key) whereas change password is more like (you changing your own lock because you do not trust your previous key) it does not involve the other party to provide grace.

@resdac Perhaps I'm using a broader definition of 2FA than is commonly used, but I consider email identity verification to be a second authentication factor. Also, while I like your analogy, I think a more appropriate one for changing your password on a web service is that of changing a lock on a rented office. You've paid for exclusive access to a certain area but changing the lock should still require additional verification, because you don't own the front door. The fact that most password change interactions don't do this is because they use the "owned environment" metaphor, which is only true on machines you fully control. It's an implementation designed according to a misunderstanding, not the correct way of handling it.

@powerfulparadox i get where you are comming from concidering the 2fa point. But why first lock yourself out then calling the owner for a new key instead of changing it yourself. It is your key. By handing in the previous one context should be clear that there is a new key. If your analogy was correct. I'd be openly sharing my private space and password with the owners. However, i'm hopefully not because my personal information is filled in by me and they should not be able to change that. That is the reason why if you rent, there has to be a notice before your landlord can actualy come in for inspection. (Atleast in my country)

@resdac All analogies have weaknesses, of course, but you seem to be devaluing the idea that, while it's your key, it's not your space. It's still whoever operates the server(s)' space, and they're letting you use it. The area where the real estate analogy breaks down is that (usually, there are methods of circumventing them) there are other identity factors which limit others' malicious access to keys they shouldn't have. Since it's much easier to impersonate legitimate renters online, it makes sense for conscientious server operators to perform identity verification for all access changes on their server. They don't need a copy of the key, just a contractual, "all lock changes (re-keying) must be approved with accompanying identity verification to prevent fraud." A smart user will understand that keys can be compromised and that verification after access is a legitimate safeguard, especially if multiple forms of identification are not required for access.

@powerfulparadox okey that is actually a very good explanation. I might even consider changing the locking system on my own pages. it is logical if you think about it. They got your key when they broke in. So changing the key with a potentially highjacked key is not secure.

@resdac I'd actually implement such a system so that if 2FA logins are active you can change your password without further identity verification (because you've already proved your identity) but without it all password changes must be approved through an email activation process. It's a variation of the ID cards and keys method used in physical businesses, where employees have keys, but also wear ID badges. If everyone does their job properly, a key isn't the only valid item enabling access, and changing one does not completely deny entry to one entitled to access (it just complicates it).

You also misinterpreted my analogy. The landlord must maintain control of the door keying because they have the legal right to access (restricted greatly, obviously, because it would be foolish to trust someone keeping unlimited access to space they rented to you for your use, as well as the legal protections) and can have legal reasons to deny you access (if you breach the rental agreement).

@SanitizedOutput The basic idea is to prevent someone who has stolen your password from changing it and your associated email address, thereby locking you out of your own account. (Changing either one should require additional verification to prevent this.) As someone who almost lost an account because both of these were changed (I only managed to salvage the situation because they allowed password reset codes sent to phone numbers and the thief hadn't changed that) it's probably more personal for me than it might be otherwise, but I still think it's a good idea to remember that good security practice can often have one more step than we'd normally think is necessary.

Again, proper 2FA makes that step unnecessary, because you've done the verification up front. This would only be necessary in systems and accounts that don't have 2FA active.

@SanitizedOutput You misunderstood me, apparently. I was originally arguing that having a separate "change password" option need not be inherently less secure than a "forgot password" option, if appropriate identification factors were implemented. Then I had to clarify why asking for additional identity verification within your own account should make sense in this one set of cases, which might have clouded the issue.

The point (which I think we agree on) is that account compromise is bad. With proper 2FA, compromise gets headed off, because an attacker has to compromise an entirely unrelated account/system to actually gain access. What I'm arguing for is a form of "last-ditch 2FA" for accounts without proper 2FA that prevents changing important account information such as passwords and contact methods without approval through one of those contact methods, which minimizes scope for hijacking. It's a holistic last line of defense if you're going to allow doing it wrong up front.