back
94 comments
This is equivalent to basic HTTP authentication. If used over TLS it's safe-ish: The real issues arise from servers logging HTTP requests/headers and whatnot in plaintext. The two benefits of using a session over the raw password are that:

1) sessions are typically scoped in time, and

2) if the session is revealed, it can't be used for credential stuffing (using the same credentials on a different website to see if the password was used there too.)

Having said that I'm not being an apologist: The design should be better

Performance would be another benefit, wouldn't it? Password hashing algorithms are deliberately slow, so doing it for every request adds some overhead compared to doing it once and establishing a session ID. (Assuming that the passwords are hashed on the server.)
Nobody's hashing a password on every request. In this case, the cookie is used for a (very shoddily implemented) "Remember Me" feature, so the user doesn't have to login to the website every time they use it.
If you're sending the password in plaintext with every request and using it for authentication (e.g. using HTTP basic authentication) you're essentially logging in with every request, so you will have to hash the password in order to validate it, unless you're storing it in plaintext on the server as well.
> HTTP authentication

Just clarifying, do you mean basic auth with the `Authorization: Basic base64(username : password)` scheme?

Which can also be sent in the URL like: https://username:password@example.com

But this is of course even worse because most servers log this. Headers are not often logged.

I'm fairly certain that's just a convenience. The HTTP client will transform that into basic auth header in the actual request
Most servers obviously by default do not log the password, all of the ones I checked do not even have a way to do so.
"Use of the format "user:password" in the userinfo field is deprecated."

https://www.ietf.org/rfc/rfc3986.txt

FYI

yeah -- updated.
I wonder what forum stack they use...

Asking as someone who works with forum software on a daily basis.

Judging by the network tab, it looks like they wrote their own. All the api requests fall under the same domain.

https://forums.lenovo.com/api/v1/user/getCountryByIp https://forums.lenovo.com/api/v1/forums/getForumAccess https://forums.lenovo.com/api/v1/forums/getCurrentForumTrees https://forums.lenovo.com/api/v1/topic/getTopic?fid=6&tid=51...

Also interesting that they have no auth requirement on the getCountryByIp route

They seem to consistently mis-spell "community" in the code, which is kind of interesting:

  var __currentForum = 
  window.CommuntiyForums&&CommuntiyForums.findCommuntiyHomepageByUrlPath()||'';
            if(__currentForum&&__currentForum.hit){
                lmdBrandVal = "Forum Details:"+ __currentForum.forum.board;
            }else{
                var __websiteInfo = sessionStorage&&sessionStorage.websiteInfo ? sessionStorage.websiteInfo : sessionStorage.currentCommuntiySite;
                if(__websiteInfo&&JSON.parse(__websiteInfo).board) {
                    lmdBrandVal = "Forum Details:" + JSON.parse(__websiteInfo).board;
                }
            }
I inherited a codebase like this, from a developer coding in their native language. Function names or variables started with a typo, and they just carried on with tab/auto completion from then on.

By the time I arrived the damage was wide and it was easier to leave it consistently wrong than try and fix across several codebases.

BuiltWith says that the CMS used at forums.lenovo.com is from Lithium Technologies, and it was first detected in July, 2012. I'm not sure if this is the forum software, or something else.
Lithium is now Khoros (https://khoros.com/), which is in pretty broad use.
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.

  Server 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.
Servers 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.
There 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.
The server knows the plaintext password in order to hash it, salt it, and compare it. How else would it do that
No, the server doesn't "know" the plaintext password, the server knows the hashed password and the salt. The plaintext password is in memory during your login request's lifetime, once it is hashed and compared against the stored hashed password, the plaintext version no longer exists on the server.

Very different case from storing them in plain text in the database or elsewhere.

Not always. The client could salt and hash the password before sending it to the server for storage and comparison.

To be clear: a properly designed system can and should operate without the server ever knowing the plaintext password.

The browser can do it too, Keybase handled passwords like that.
I thought it could get hashed client side
Session 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.)

* 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.

That's a fair point. I guess I was speaking in the more general case, but yes, you can have multiple layers of authentication and it is super implementation dependent. Everyone has their own threat model (hopefully!).

(I wrote a few thousand words on MFA a year or so ago: https://fusionauth.io/learn/expert-advice/authentication/mul... )

There 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)

That'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-p...
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.

Nothing stops a hacker from siphoning all the credentials from a login page either. Servers have to handle plaintext passwords regularly.
If 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.

We 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.
Yes. 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.
> Yes. It is not easy to 'logout' when the browser knows your basic auth credentials.

Return a 401 on the "logout" page?

Not in any way a web dev, but couldn't an XSS on Lenovo's site make it possible to leak these?
> 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.

it's all the same- biscuits, macaroons, maybe next we can do churros or something.
I just tried to replicate this issue (because I wanted to see it in action).

I was able to sign up and sign in repeatedly. I never saw a 'RMEPass' cookie set, nor was I able to click 'remember me'.

So it seems like they have fixed at least one part of this issue.

Or mitigated the issue by disabling the affected feature.
Fair, hard to know which.
I don’t see a “Remember me” option [1] on the login form anymore. Maybe they’ve removed it until this can be properly resolved?

[1]: Screenshot at https://forums.lenovo.com/t5/Other-Linux-Discussions/Thinkpa...

From Jan 31.... Wonder if this has been fixed yet
Yeah, tested. They fixed.
Did you select “Remember me” in your test?