Timeline for Client Side Hashing + Server Side Hashing
Current License: CC BY-SA 4.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 26, 2019 at 16:04 | vote | accept | Seth Falco | ||
| Aug 26, 2019 at 3:51 | history | edited | Theraot | CC BY-SA 4.0 |
added 3661 characters in body
|
| Aug 26, 2019 at 3:45 | comment | added | Theraot | @Seth expanded my answer. | |
| Aug 26, 2019 at 3:45 | history | edited | Theraot | CC BY-SA 4.0 |
added 3661 characters in body
|
| Aug 26, 2019 at 3:08 | comment | added | Theraot | @Seth yes, I would advocate for unique passwords, at least for anything that has any sensible information, regardless of anything else. For any given organization there is virtually no incentive to try to protect the account of the user on other platforms or services after their own was compromised, I would argue that it is better for any given organization to expend the extra effort in making sure they do not get compromised. However, I will expand my answer, I think there is something else we can talk about here. | |
| Aug 26, 2019 at 2:11 | comment | added | Seth Falco | That very small win was the thing I was hoping from this. My scenario where I mess up, log the passwords, and now my system admin can see them, and decided to "have fun" or dump them. While I agree with you that hash becomes their effective password, it was intended to reduce the reusability of it to other services the user may use by storing it differently if they reused passwords. - Very specific scenario... Very small beneficiaries I'll admit. - Overall can I verify, so it sounds like you're saying it's better to not bother and advocate unique passwords, or a password manager? | |
| Aug 26, 2019 at 1:10 | history | answered | Theraot | CC BY-SA 4.0 |