rejetto forum

Alternative login form for modern browsers

LeoNeeson · 19 · 16205

0 Members and 1 Guest are viewing this topic.

Offline rejetto

  • Administrator
  • Tireless poster
  • *****
    • Posts: 13510
    • View Profile
guys, i want to make this system the new standard, not just an extra as initially designed.
i want to have better names instead of the __USER.
I'm going to use the existing ?mode in the url, so we'll have mode=login and mode=logout
no __AJAX anymore
in POST data (in the future maybe also in GET) the names for the login will be simply: user, password, passwordMD5, passwordSHA256
logout needs needs no user

the default template will use this.
« Last Edit: May 12, 2020, 09:42:19 AM by rejetto »


Offline Rapid

  • Occasional poster
  • *
    • Posts: 49
    • View Profile
    • R&Q Portal
Hi Rejetto!

I think, that for security reasons saving in preferences password or MD5(password) or SHA256(password) are all equally bad.
For MD5 we had rainbow tables, and maybe for sha256 will be something similar.

Saved should be only password hashed with salt.

For example there is experimental RFC: https://tools.ietf.org/html/rfc7804
According HFS, salt can be generated one per VFS.

Could you make switch for sha256 function? Like if protocol is https than use browsers implementation? I think it should be more optimized than js version


Offline rejetto

  • Administrator
  • Tireless poster
  • *****
    • Posts: 13510
    • View Profile
hi Rapid, i see your point, and there's some truth.
Anyway, hashing would be better than the simple base64 encoding we have now, and that's what i could introduce with little work.

People here have to understand that we are discussing server storage security, in case you get access to settings on the server. We are not discussing login security.

Back to our point, let's see... if in the future we'll have also a 'salt', the server will have to pass it to the client (along with the session), and the piece of scheme hash(pwd) will become hash(pwd+salt).
We can consider it being already like this, with salt as empty string. The current scheme seems to be compatible with this future requirement, and templates can already be build this way to be future proof.
I hope I was clear enough on this, and that you agree with its consistency. Thanks for making me think on this, i didn't  before.

Quote
Could you make switch for sha256 function? Like if protocol is https than use browsers implementation? I think it should be more optimized than js version

more code to optimize what? 1ms total on the browser's CPU ? :)
« Last Edit: May 15, 2020, 02:08:37 PM by rejetto »


Offline LeoNeeson

  • Tireless poster
  • ****
    • Posts: 842
  • Status: On hiatus (sporadically here)
    • View Profile
    • twitter.com/LeoNeeson
Saved should be only password hashed with salt.
and that's what i could introduce with little work.
I agree and understand on the security points (and I already know we are talking about the server side, not the client side), but I have 2 considerations to suggest you keep in mind:

1) make this optional (I'm talking about saving password hashed with salt), why? because what happens if the user lost his password, or if you use this only between family members (and then need to remember someone his password). Reset password could be handy, but it's cumbersome if HFS is used only between trusted members.
2) if this is implemented, I'm having an idea to suggest about having a way to manage sessions. I will describe this idea much better on a future post this weekend, now it's late and don't have time to leave the whole idea on how this works (my idea doesn't affect directly this, it's a supplementary thing, so, if you want to work on this, don't wait for my comment).

That said, I'm not against this (on the contrary, I think it's a cool feature for those who need it) :)
Cheers,
Leo.-
HFS in Spanish (HFS en Español) / How to compile HFS (Tutorial)
» Currently taking a break, until HFS v2.4 get his stable version.