request.vars.password in clear text is that normal?

[Richard]

Hello,

I found that my app logging feature is collecting password in clear text when I do request.vars to collect and store these data in a request_vars field...

I wonder if I had to handle the hiding of the password myself? I was thinking that password was obufuscated somehow by web2py...

Is this normal behavior (recovering request.vars.password in clear text), so I have to obufuscate it myself is something leave in web2py build (2.14.6) as it occurs sometimes that the password shows up in traceback even if not suppose to be exposed??

Thanks

Richard

[Niphlod]

you are the logger.... you choose what to log. the password the user types in in the browser is in clear text.

[Richard Vézina]

Thanks that what I want to know, I thought it could have some particularities for password field that would had encrypt password at the source somehow as a kind of handshake where the password is never passed over the wire.

So, there is not.

Thank you

Richard

--
-- mail from:GoogleGroups "web2py-developers" mailing list
make speech: web2py-developers@googlegroups.com
unsubscribe: web2py-developers+unsubscribe@googlegroups.com
details : http://groups.google.com/group/web2py-developers
the project: http://code.google.com/p/web2py/
official : http://www.web2py.com/
---
You received this message because you are subscribed to the Google Groups "web2py-developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web2py-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Anthony]

On Thursday, March 23, 2017 at 9:49:45 AM UTC-4, Richard wrote:

Thanks that what I want to know, I thought it could have some particularities for password field that would had encrypt password at the source somehow as a kind of handshake where the password is never passed over the wire.

Then we would have to send the per use salt to the browser.

Anthony

[Richard Vézina]

Which would involve security issue??

--

[Anthony]

On Friday, March 24, 2017 at 10:58:18 AM UTC-4, Richard wrote:

Which would involve security issue??

Maybe not a security risk, but an extra request. Actually, the real problem is that the (client-)hashed passwords become the real passwords, and we ending storing real passwords in the database. The point of the hashing is not simply to obscure the password but to ensure that the server is not storing the very token sent by the client for authentication. If the password is hashed on the server, someone who hacks the server and gets the password database cannot use the hashes to log in. However, if the password is hashed on the client, then getting access to the hashes stored in the database would allow someone to use those hashes to log in.

I suppose you could hash on both the client and the server. That would protect the user's original password from leaking on the server, but you could still see their client-side hashed password, which is actually all that is needed to log in anyway, so there is no extra security regarding the web2py app. The only additional benefit to the user is if they use the same password on multiple websites -- in that case, I suppose their security on other sites where they use the same password would improve marginally if their web2py password were hashed client side.

Anthony

[Dave S]

And isn't the move to HTTPS/SSL motivated by wanting to protect clear-text passwords (and other user data) in transit?  If the concern is about data at rest, don't log it in plaintext and do practice good session management.

(How accessible is session data outside of the application?)


/dps "Look for the lock in the address bar!"