11 ms·
As long as it's a http only secure cookie... it should not be a huge issue. Session ids are basically replacement for username+password anyway, and nobody cares
by megous 5y ago
As long as it's a http only secure cookie... it should not be a huge issue. Session ids are basically replacement for username+password anyway, and nobody cares they're stored in a cookie. Server knows the plaintext password already, too.
So the only remaining issues are security issues around sharing your computer with other people, or programs. I guess stealing a session id is mildly less problematic than stealing the password in case the password is re-used elsewhere.
- deleted 5y ago[deleted]
- 0des 5y agoit's all the same- biscuits, macaroons, maybe next we can do churros or something.
- skeeks 5y agoAnd 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 5y agoNothing stops a hacker from siphoning all the credentials from a login page either. Servers have to handle plaintext passwords regularly.
- djtriptych 5y agobut only ever in memory. writing to disk is the issue here.
- UncleMeat 5y agoBut there is no evidence that they are writing the passwords to disk.
- djtriptych 5y agoI'm talking about authenticating servers in general, not just lenovo.
- lxgr 5y agoThey are writing the passwords to users' disks at least, which by itself is already really bad and easily avoidable.
- UncleMeat 5y 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 5y 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 5y ago[deleted]
- foobarbecue 5y agoNo. Servers should never see the actual password. What case are you imagining where they need to?
- hardware2win 5y agoTo generate tokens?
- born2discover 5y 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 5y 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 5y 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 5y ago
- deleted 5y ago[deleted]
- megous 5y 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 5y 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 5y 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.
- eptcyka 5y agoWe know that people love to reuse passwords. We also know that enterprise software is often deployed in a rather complex, complicated, multi-layer fashion, which is to say that misconfiguring it to not use HTTPS isn't all too far fetched. Leaking a session ID is always strictly better than leaking a plaintext password and username combo.
- briffle 5y agoServer knows the plaintext password already, too. Servers should NOT be storing passwords in plaintext, ever. This has been clear for at least 20 years now. You should only store a salted hash of a password, and please, do not roll your own. Use one of the many popular libraries for this.
- megous 5y agoServers routinely handle plaintext passwords when authenticating. They may not store it, but it's not something that is invisible to them, unless using some auth method that uses challenge/response instead of plaintext passwords. Most web apps use plaintext password auth.
- Kwpolska 5y agoThere is a difference between the plaintext password being stored in memory and in a database. One is just how things work (the client browser needs the password in plaintext as well), and another is a security breach waiting to happen.
- adolph 5y ago> There is a difference between the plaintext password being stored in memory and in a database. Yes, if you already got in, then reading RAM for active users is much more convenient than exfiltrating a bunch of potential trash accounts.
- pdpi 5y agoAny non-brain dead design will keep the password around only long enough to hash it and compare that to the store hash, and then promptly get rid of it. You can’t just read passwords from memory as if it were an open book.
- adolph 5y agoAttacks, as opposed to data breaches/exposures, may occur over longer time periods and sample memory as they go. Iirc, the attacker in The Cuckoo’s Egg both read password files and temporarily patched the login form.
- mooreds 5y agoSession ids != usernames/passwords. Not even close. Why? * Re-use across sites: people unfortunately reuse passwords across services. That means that getting access to these cookies would be great for credential stuffing attacks. A session identifier is no use for that type of attack. * Re-auth across devices: you can't typically exchange a session for another session on a different device, but you sure can do so with a password. * Session ids can be revoked with less user impact (they have to log in again). Passwords can be revoked too (it's a password reset), but it impacts users far more. As other comments mention, passwords should be manipulated in memory, only stored hashed and salted by a strong algorithm, and seen by the bare minimum of software. Preferably handled by software designed for handling passwords and other sensitive credentials. There are commercial options, free options, and open source options. (Full disclosure, I work for an auth company.)
- nirui 5y agoThere are considerations on the performance as well. Usually, a responsible website will password-hash the plain-text password into a hashed string before saving the hashed string into their storage. Password-hash is a special hashing process designed to be reasonability slow, so an attacker who somehow obtained the hashed string cannot easily collide the hash with another plain-text. Some password-hash configuration can took few milliseconds to run, that's really expensive if you have to do that for every request just so you can compare the client password-hash v.s. the one stored on your server. (Full disclosure, I designed few session manage systems for my job before :D)
- mooreds 5y agoThat's a great point. Hashing makes it more painful to credential stuff. I had a colleague write a few thousand words on the topic: https://fusionauth.io/learn/expert-advice/security/math-of-password-hashing-algorithms-entropy https://fusionauth.io/learn/expert-advice/security/math-of-p...
- megous 5y ago* Re-auth across devices: you can't typically exchange a session for another session on a different device, but you sure can do so with a password. Ever had Google deny you access for a perfectly valid username/password combo when loging in from "unfamiliar" location? :) Or a bank ask you for SMS code when logging in from a different browser? It really depends on level of paranoia of the authentication system. You can have user device validation even with username/password, and you may not have it for session IDs in a different implementation.
- dankboys 5y agoNot in any way a web dev, but couldn't an XSS on Lenovo's site make it possible to leak these?
- ElectricalUnion 5y ago> an XSS on Lenovo's site make it possible to leak these? Not if they're HttpOnly cookies. Then it requires actually compromise/mitm of the application server code to recover the cookies.
- blenderdt 5y agoYes. It is not easy to 'logout' when the browser knows your basic auth credentials. Even if the server sends a new cookie that will overwrite the basic auth cookie the browser might send it again.
- ElectricalUnion 5y ago> Yes. It is not easy to 'logout' when the browser knows your basic auth credentials. Return a 401 on the "logout" page?