Am 22.05.2014 16:12, schrieb Cor Bosman:
hint: you can't do without
Maybe the roundcube devs can explain which attack vector they are trying to prevent by having CSRF on the login page
i am not a roundcube dev but my job is development and security
- if you don't pass the token verification no login code is running
- the login in case of roundcube implies network connections
- the login in case of roundcube affects also the mailserver
the django project thought the same as you: https://www.djangoproject.com/weblog/2013/sep/15/security/
conclusion: whereever it is possible protect any expensive action with tokens, there are people out there thinking day and night how they can abuse things nobody imagines how they can be abused until it happened
The only attack vector I see is that you can be fooled into thinking you’re in your own account
*why don't you click on the link i posted* below the *content* of that link
and *after that* issue *many* smart people started to implement CSRF protection in the login process because it avoids completely to deal with the credentials
https://www.djangoproject.com/weblog/2013/sep/15/security/ ___________________________
Issue: denial-of-service via large passwords
Django's authentication framework -- django.contrib.auth -- includes a default User model and backend which authenticates via username and password. The raw password is not stored in the database; instead, a hashed version of the password is stored, and the hash is computed each time a user attempts to log in. The hasher to use is configurable, via the PASSWORD_HASHERS setting.
The default password hasher in Django is PBKDF2, which has the virtue of allowing the complexity of computing the hash to be effectively arbitrarily high, by repeated "rounds" of application before producing the final result. This increases the difficulty of attacks which use brute-force methods to compute the hashes of many possible plaintext values, in hopes of discovering which plaintext password corresponds to a given hashed value.
Unfortunately, this complexity can also be used as an attack vector. Django does not impose any maximum on the length of the plaintext password, meaning that an attacker can simply submit arbitrarily large -- and guaranteed-to-fail -- passwords, forcing a server running Django to perform the resulting expensive hash computation in an attempt to check the password. A password one megabyte in size, for example, will require roughly one minute of computation to check when using the PBKDF2 hasher.
This allows for denial-of-service attacks through repeated submission of large passwords, tying up server resources in the expensive computation of the corresponding hashes.
Although this is most effective against algorithms which are designed to be relatively "slow" to compute, such as PBKDF2 (which, again, is the default hasher in Django's authentication framework), it also is effective against other hashers, as the time to compute the hash generally grows with the size of the password.
To remedy this, Django's authentication framework will now automatically fail authentication for any password exceeding 4096 bytes.