Demos don't follow best practices about aiohttp-security HOT 6 OPEN

This appears to extend to the more complete aiohttp demos as well:
https://github.com/aio-libs/aiohttp-demos/blob/master/demos/blog/aiohttpdemo_blog/db_auth.py

from aiohttp-security.

@asvetlov More generally, what is the rationale for this advice? What issues might we face by revealing the user ID or login?

Worth noting that this isn't even revealed when using the session backend with EncryptedCookieStorage, as the session is encrypted.

from aiohttp-security.

My 2 cents:
If the identity is user login and it is stolen, attackers can login with your login. Since your login usually doesn't change, you don't have a way stop the bad actor.
Using an EncryptedCookieStorage still has the same risk above. That is, as long as I have your encrypted session, I have your account.

from aiohttp-security.

I feel like if you can access a cookie, you can probably also access the user's login details anyway. Expiry times can also reduce this risk.

If developers want to ensure that a session can be revoked, then it would be a good reason to use something different for the ID. However, revoking a session needs to be an explicit feature that they plan for and implement. The tradeoff is that you now also need a DB call to validate the session on every request.

So, I still feel that strongly discouraging users from using a user ID isn't providing any benefits. We could expand the documentation to talk about these different strategies and their tradeoffs though. Maybe also link to the Oauth documentation which seems similar here in terms of tradeoffs of token designs: https://www.oauth.com/oauth2-servers/access-tokens/access-token-lifetime/

from aiohttp-security.

@yanxurui the stolen login does not allow the attacker to login, they'd need a session id or a login password.

User id's are generally not considered secrets. They show up in server logs (so activities can be tracked to users), in forum posts (to allow other users to recognize postings made by the same user), in helpdesk tickets (so helpdesk persons can look up what happened).
It's the passwords, the additional factors in 2FA, the session ids which are considered secrets.

from aiohttp-security.

Hi @toolforger , yes your are correct that there is no risk if the login itself is leaked. However, it's a concern when the the login is used as the "identity" in this module.

from aiohttp-security.