4 ms·
And what if the server is compromised in the future? It is trivially to then extract all the cookies and send them to a attacker-controlled server. The attacker
by skeeks 4y ago
And what if the server is compromised in the future? It is trivially to then extract all the cookies and send them to a attacker-controlled server. The attacker then uses those password to try to login on different platforms.
After initially setting a password, the database/server should only store a salted hash.
No exceptions.
- invokestatic 4y agoNothing stops a hacker from siphoning all the credentials from a login page either. Servers have to handle plaintext passwords regularly.
- djtriptych 4y agobut only ever in memory. writing to disk is the issue here.
- UncleMeat 4y agoBut there is no evidence that they are writing the passwords to disk.
- djtriptych 4y agoI'm talking about authenticating servers in general, not just lenovo.
- lxgr 4y agoThey are writing the passwords to users' disks at least, which by itself is already really bad and easily avoidable.
- UncleMeat 4y agoHow is that bad? If you've got malware on your machine then you are already fucked. Desktops don't tend to have strong process isolation that keeps malware from reading a password in flight anyway.
- icedchai 4y agoOften, it is plaintext over the internal network. A TLS/SSL terminating load balancer decrypts the traffic, then your request is in clear text as it hits the internal web or app server. It can be sniffed and logged without modifying the application.
- deleted 4y ago[deleted]
- foobarbecue 4y agoNo. Servers should never see the actual password. What case are you imagining where they need to?
- hardware2win 4y agoTo generate tokens?
- born2discover 4y agoI believe they are referencing the fact that upon a login attempt the server does receive a plaintext password per se. Usually it is stored in memory only long enough to compare it to the hashed version from the persistence layer but... that's in theory.
- tuwtuwtuwtuw 4y agoWhen it comes to memory then it will typically be stored longer than necessary due to how garbage collection works in 99% of all of web applications.
- coder543 4y ago> Servers should never see the actual password. Are you actually doing client-side hashing in addition to hashing on the server side? Otherwise, yes, the server does see the password. In most applications, a compromised server could just serve a login page that doesn't do the client-side hashing anymore if the malicious actor wanted to collect credentials, so I don't see how this added complexity is really adding any security. The real way to add more security is to minimize dependence on passwords by implementing a better, second factor of authentication, such as TOTP, WebAuthn, SSO, or even SMS or email tokens. Unless a person is using a password manager to generate their passwords, then passwords are almost always terrible and weak, and usually reused across sites. More of my opinion is shared over here[0]. [0]: https://news.ycombinator.com/item?id=30559443 https://news.ycombinator.com/item?id=30559443
- CorrectHorseBat 4y ago
- deleted 4y ago[deleted]
- megous 4y agoIf server is compromised, passwords are compromised too regardless if they are hashed or not. I can selectively deauth a user to make them login again in short order and take his password. It depends on the level of compromise, of course.
- Tepix 4y agoIf it's a short breakin where someone manages to dump the DB it makes a big difference. Strong hashes are the way to go.
- BenjiWiebe 4y agoRe deauthing. This sort of attack isn't nearly as useful if the server is something like a bank where most users only log in once in a while and don't access the account at all in between.