Created on 2020-06-03.11:15:23 by nicoe, last changed 1 week ago by nicoe.
* Roundup Robot [2021-02-21 22:25 +0100]: >New changeset 090dc40da49d by Cédric Krier in branch 'default': >Add default value for new device_cookie >https://hg.tryton.org/trytond/rev/090dc40da49d Which consumer code is impacted? I had thought about adding a default value to those functions but decided not to put them because it would mean that any successful login would reset the count for unknown devices.
New changeset 6837cd484370 by Cédric Krier in branch 'default': Add default value for new device_cookie https://hg.tryton.org/tryton-env/rev/6837cd484370
New changeset 090dc40da49d by Cédric Krier in branch 'default': Add default value for new device_cookie https://hg.tryton.org/trytond/rev/090dc40da49d
New changeset 12222c9e5e00 by Nicolas Évrard in branch 'default': Protect trusted devices against brute force attack https://hg.tryton.org/tryton-env/rev/12222c9e5e00
New changeset d3a8ed75e4c0 by Nicolas Évrard in branch 'default': Protect trusted devices against brute force attack https://hg.tryton.org/trytond/rev/d3a8ed75e4c0
New changeset e4bfb7718b16 by Nicolas Évrard in branch 'default': Protect trusted devices against brute force attack https://hg.tryton.org/tryton/rev/e4bfb7718b16
New changeset d10e0a87299d by Nicolas Évrard in branch 'default': Protect trusted devices against brute force attack https://hg.tryton.org/sao/rev/d10e0a87299d
We get sometimes the remark that the exponential wait in the get_login function when the user enters is useless or should be changed in order to reduce the delay (see issue5375 and other discussions about that on the opensuse bugtracker or in live). Getting some idea from https://owasp.org/www-community/Slow_Down_Online_Guessing_Attacks_with_Device_Cookies we think that we could use a random token store on the client side and on the server side in order to reduce the wait for users trying to connect from a client that has already been trusted. This token would be sent alongside the credentials information and if it matches the one store on the server then the user wouldn't have to wait in order to make another attempt. Of course if the number of attempts reach a defined limit then we will sent a 429 - Too Many Requests.
History | |||
---|---|---|---|
Date | User | Action | Args |
2021-02-22 09:43:30 | nicoe | set | messages:
+ msg64775 status: resolved -> chatting |
2021-02-21 22:25:15 | roundup-bot | set | messages: + msg64767 |
2021-02-21 22:25:04 | roundup-bot | set | messages: + msg64765 |
2021-02-21 22:22:53 | ced | set | component: + tryton, trytond, sao |
2021-02-21 22:22:41 | ced | set | assignedto: nicoe type: feature request |
2021-02-21 16:23:42 | roundup-bot | set | messages: + msg64739 |
2021-02-21 16:23:34 | roundup-bot | set | messages: + msg64738 |
2021-02-21 16:23:31 | roundup-bot | set | messages: + msg64737 |
2021-02-21 16:23:27 | roundup-bot | set | messages:
+ msg64736 nosy: + roundup-bot status: chatting -> resolved |
2021-02-16 12:10:09 | reviewbot | set | messages: + msg64636 |
Showing 10 items. Show all history (warning: this could be VERY long)