Skip to content
This repository has been archived by the owner on May 15, 2024. It is now read-only.

Home

Jump to bottom
Henk Verhoeven edited this page Feb 7, 2014 · 21 revisions

Everything here is open for discussion.

Roadmap

Things i definitely want to do:

  1. Create indexes in the database, add the Data definition SQL to the install documentation,

  2. Make unit tests run also from the command line,

  3. Register end DateTime of RequestCounts. Currently counters that start before 'blockIpAddressesFor' ago are not added to the totals. This may be contra intuitive to developers making the settings. Safer is to store and use a 'dtUntil' or 'dtThrough' field specifying when the counting period ends. Counters that start before 'blockIpAddressesFor' ago but end afterwards will then be added too.

  4. The user agent in the RequestCount keys will lead to too many records under brute force attacks 1). Do not use user agent, replace by support for long term cookie token (setting and retrieving the cookie will remain NYI for now)

  5. Releasing for more IP adresses. Currently releasing by username is either for all IP addresses (including those that have misbehaved) or only for a specific IP address and user agent. This could be extended to other IP addresses that are not blocked by address and do not have more then the limitPerUserName failures for the user name.

  6. Add a function for clean-up of the RequestCounts table. Records older then the longest of the configured durations are useless and slow down the retrieval. They can be deleted.

  7. Add RequestCountsManagerInterface and Manager to facilitate custom NoSQL storage of RequestCounts 1)

  8. Remove Requestcounts entity, limit depency from Doctrine to DBAL,

  9. Make a separate repo on Github with a composer library with those parts that do not require Symfony (primarily the TresholdsGovernor and the RequestCountsRepository class)

  10. Add complete api docs

  11. Make the database queries independent from Doctrine (use plain SQL, add support for running them on PD directly (? can DBAL QueryBuilder be used with MongoDB? If so, make KISSQueryBuilder for PDO, if not plain SQL is the simpelest solution)

Ideas

These i may do at some point, or others may do them, but it's hard to say if and when.

  • Periodically pack the Requestcounts table. If one of the durations is substantially longer then the others, records that are older the the shorter duration ago may be packed into ones with a longer counting duration.

  • Estimation of credibility. Currently only the number of failed logins per IP address count. This may result in the blocking of adresses that harbour many users. Other measures could be taken into accout, like the number of successfull attempts over a longer duration.

  • Releasing by long term cookies. On a successfull login a long term cookie could be set and stored in the RequestCounts record intstead of the user agent (Choice could be made configurable). This would also help against flooding of the RequestCounts by random user agent strings sent in brute force attacks.

  • Add (example) Controllers and templates for sending e-mails with urls with release tokens and for processing the resulting release requests.

  • Fulfilling more OWASP requirements (discussion). Important: timeouts.

  • Adding more Guard classes for different types of Authentication Listener, or replacing it by other hooks into symfony's authentication (discussion)

  • Keep track of usage that is a-typical for legitimate application users 2). For example an Exception Listener that tracks and counts routing exceptions and invalid parameter exceptions. It could send e-mails to security officers, and/or lock out a user until he/she requests na e-mail for reactivation after password change. IMHO this would be a separate bundle, so out of the scope of this one.

Notes

1) The importance of this was suggested by Remko Silvis at GroningenPHP, februari 2014

2) Suggested by Aukje Holtrop at GroningenPHP, februari 2014

Clone this wiki locally