Whistleblower access should be subject to an expiration time different from the data retention policy

[evilaliv3]

Most of the users are doing bad use of the platform as for practical reason are always putting the data retention policy limit big near to infinite.

This is acceptable in relation to the data retention policy, but not acceptable in relation to the possiblity for an attacker to get more chance in accessing existing submissions.

This require to be handled, and the best solution is to split the whistleblower access timetolive from the data retention policy timetolive.

This ticket is to keep track of the changes needed in order to implement automatic expiration of the whistleblower access that should be subject to a timeout related to the last access of the whistleblower.

[evilaliv3]

By default i will set it to 3 months and make the whistleblower reset it by simply logging onto the platform.

I think that always when customized, the value of this timeout parameter should be studied and its value should take into account:

• the data retention policy
• the receipt complexity (currently set to 16 digits)

[evilaliv3]

@NSkelsey check it out! ;)

[fpietrosanti]

Security documents should be updated accordingly for what's related to anti-bruteforcing protection's references

[NSkelsey]

TODO these changes should be ported into master to satisfy the requirements of an adopter before September.

[evilaliv3]

I agree.

This is now a requirement for most of the public administrations and enterprises where the data retention policy choice, in relation to some law requirements or some procedures is too broad.

[NSkelsey]

The implementation which I am porting from Browser crypto into devel, does not generate a notification to the receiver before a Whistleblower's access to the tip expires.

We can modify check_for_expiring_submissions to send email for tips that are expiring as well. Once the wb_tip is gone there will be no chance to return access to the WB.

[NSkelsey]

A few notes:

1. Instead of an email, a dialogue that is shown to the whistleblower that explains that their access to the submission will expire if they do not access it within X days is a better approach

2. The tip interface on both sides needs to update to show this new piece of state. We can place a flag that lives in the tip summary box.

3. The tip list interface needs either an extra column or some way to signal that tips are in an archived state. This relates to pagination of the tip list interface.

More notes:

4. For now this will be a dumb feature. There will be no opportunità for the receiver to postpone or disable WB access.

[NSkelsey]

This is what the current implementation looks like, (we've added a column)

With a popover:

And when access is revoked:

[NSkelsey]

I have been testing the implementation of this feature.

When access is revoked the following log line is generated:

2016-07-20 21:35:12+0200 [-] Disabling WB access to cd4bd5a3-a805-4667-88cf-03fece902a12

At migration time access to Old whistleblower tips should be revoked. Otherwise the scheduler will expire a whole bunch at 00:00:00 the next day the service restarts.

[evilaliv3]

Implemented in devel; will be shipped in the upcoming release.

[evilaliv3]

This has still to be described in the application security policy.

In addition i would suggest that the implementation reset the access expiration every time the whistleblower access. This way whistleblower that are active and log for checking their submission and possibly update it do not see their access expire; obviously in case the submission expiration time the access to the tip will expire as well with no possibilty for the whistleblower to keep it alive.

[NSkelsey]

@evilaliv3 this is what the current implementation does.

[NSkelsey]

Documented.

[evilaliv3]

Great! Well done!