Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

(1) Best that would be a one usage link though, so that a user can detect, whether the link was stolen from their inbox. I think you also did not get my point: The service should not know the password at all. Usually not even initial passwords for any account. It is simply a bad practice to ever have knowledge about user passwords, except for a salted hash. So I say you are wrong.

(2) The server gets send the password via the default communication channel, the browser, TLS hopefully, not via e-mail, possibly into an inbox, that is third-party controlled (say some google mail inbox for example).

(3) That does not make it right. Did they even ask the users for their consent? Did they learn anything from GDPR or in general discussions about consent? Or are they just a higher being, allowed to decide for their users, what data about them they track?

Many things can be done using technology. The question is always: Should we do them? That is a question about ethics, not technological possibility. We already have far too many businesses not caring about ethics at all, we do not need any additional ones.



(1) How can the user detect it? The service can request a password reset at any time. Most alerts go through emails which the provider can hide. It's only a bad practice since password reuse exists and people trust services not to exploit that fact.

(2) That is how it usually works.

(3) You can collect the information for security purposes just fine under the GDPR.

Providing a better user experience while maintaining a similar amount of security is a net positive


(1) A tool like for example https://github.com/pglombardo/PasswordPusher self-hosted offers a way for the user to detect, whether their password has been seen before.

(2) Are you missing the point? "That is how it usually works." -- So why then send a password to an e-mail inbox, like I said a location often controlled by third party and often one with no good record of respecting privacy, if you can completely avoid that?

(3) OK, seems like we did not learn about consent. Why don't you ask your users, whether they are OK with it first, instead of assuming and basing on what is legally possible? Is ethics something too far out of reach?

Lastly a word about what you call security: Your so called security is observed often enough to result in inaccessible accounts. "Extra strict" usually means something along the lines of "oh, now I am going to require your phone number, to send you a message on a second channel to make sure" or "solve these captchas for this untrustworthy third party provider and I will trust their word about you having solved it correctly" (again being tracked of course ...) or similar things. Again circumventing consent, because now it becomes an extortion, extracting more personal data, so that the user can access their account. Your so called security makes for a real shitty user experience and punishes the user for ever switchting their browser.

So what does your "extra strict" mode entail? How are you going to be "extra strict", without any extortion? Are you implementing your own captachas by any chance? Or something similar?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: