[
https://issues.apache.org/jira/browse/OAK-634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13582051#comment-13582051
]
angela commented on OAK-634:
----------------------------
just two additional comments:
1) regarding the growing map: users can change their password. having a ever
growing map
would offer a nice way to attack the system by running a script that changes
the pw
and logs-in forever.
2) the loginlogout test:
while that test is fine to get an idea on how the regular uid/pw login
performs the test itself
is only partially representative for our default adobe setup (and thus my
main use-case) which
uses a sequence of uid/pw login and subsequent token-login.
in somma: i would suggest that we keep that on the radar but i would really
want to
focus performance improvements on those areas that used to be really cumbersome
in jackrabbit-core.
the login performance wasn't identfied as problem AFAIK... that doesn't mean we
shouldn't thrive for best
performance but it should be weighted against possible problems that may arise
from optimization.
> PasswordUtility.isSame() performance bottleneck
> -----------------------------------------------
>
> Key: OAK-634
> URL: https://issues.apache.org/jira/browse/OAK-634
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
> Reporter: Jukka Zitting
> Labels: performance
> Attachments: jackrabbit.patch, oak.patch
>
>
> The default 1000 SHA-256 iterations used for password hashes are seriously
> impacting the performance of login() calls. Here's a performance report of
> the number of milliseconds that a successful login takes with Jackrabbit 2.x
> and Oak (with an in-memory MK):
> {noformat}
> # Login min 10% 50% 90% max
> Jackrabbit 560 570 577 704 1522
> Oak-Memory 2537 2586 2630 2811 2916
> {noformat}
> Over 50% of that time is spent doing hash iterations in
> {{PasswordUtility.isSame()}}. This is a problem for two main reasons:
> # It severely drags down performance of acquiring a new session; something
> which should be essentially free.
> # It opens the denial of service attack vector of just bombarding a system
> with login attempts, which would cause CPU usage to spike.
> Iterating a password hash is a good idea for preventing offline attacks
> against a stolen password database (though instead of SHA-256 we should be
> using something like bcrypt that's explicitly designed and analyzed for this
> purpose), but the current implementation doesn't make much sense in a
> scenario like ours where we can expect dozens or hundreds of logins per
> second even in normal non-peak use cases. Password iteration makes more sense
> in use cases where logins are infrequent (e.g. once a day per user) and
> persisted through something like a session key.
> So, assuming we want to keep the cost of an offline attack high, here's what
> I suggest we do for password-based logins:
> * Switch to bcrypt or a similar password hashing algorithm if possible.
> * For each active user in the system, keep an in-memory record to speed up
> login calls.
> ** On a successful login the record should be updated to contain a password
> hash with just one iteration (calculated from the plain text password
> provided in the successful login). Use this instead of the in-repository
> password hash for authenticating further login attempts.
> ** The record should also keep track of unsuccessful login attempts and limit
> them to at most N attempts per minute to prevent DOS attacks.
> The result of such in-memory record keeping should be to massively speed up
> normal logins (point 1 above) and also to cap the CPU use of the potential
> DOS attack (point 2) to O(N*K) cycles per minute, with K being the total
> number of users in the system.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
