Implement "ratchet" for sources to prove that their account was not used since last login

[heartsucker]

Feature request

Note: I didn't consider all possible cases and am just submitting this as an idea I had while at work before I forget. Hopefully discussion determines if it is or is not a terrible idea. :)

Description

A source has no way of knowing if someone other than them has used their credentials since their last login. They may want a way know that their communication channel has not be used by anyone other than them. Likewise, a journalist has no way of knowing that any messages were sent that did not originate from a true source.

This could be implemented by generating a one-time security phrase (henceforth "ratchet") at login, then displaying it a the next login. The flow would work like this.

Initial Interaction

1. Source enters codename for the first time
2. Source is shown a page with a description of the ratchet and told that if they don't see the correct security phrase at next login, then they should consider the channel compromised.
3. Source memorizes a single ratchet codeword (possibly diceware)
4. Source submits and logs out

Subsequent Interactions

1. Source logs in with codename
2. Source is redirected to a confirmation page and shown their ratchet code with the explanation of why it's important
3. If it's incorrect, the source abandons that account and may flag the account as compromised in such a way that journalists are notified. They include the last good ratchet so that journalists will be able to tell when the account was compromised.
4. If it is correct, the source is shown a new ratchet code and continues with the current flow of sending/receiving messages

Technical Details

A column would be added to the source table that has a login counter. This counter is deterministically mapped to a wordliist with some sort of unique offset so that no two source see the same work with the same counter. This would also be based on the application key so that no two applications have the same ordering for the wordlist.

This counter is used to generate the login codeword. The application checks that the wordlist has not wrapped around preventing an adversary from logging in (size of list) - 1 times to "reset" the counter and hide their tracks.

The submission table has a column added mapping to the ratchet index per message so that journalists can later see a flag for what messages were pre/post compromise.

The source table has a flag column for "compromised" and a "last good message" that would prevent a journalist from sending messages to the source.

In the UI, a journalist would be shown a warning that the source was compromised along with a marker separating good messages from bad messages.

User Stories

As a source, I want to know that only I have accessed my SD account since my last login.

As a journalist, I want to know that my source's account has never been compromised.

As a journalist, I want to know that if a source's account was compromised when it occurred so I can separate good messages from bad messages.

[ghost]

The only remark I have about this idea is the need for the source to remember / write down something unique after each interaction. It looks like a good idea though. Unless this is an original idea, there should be articles exploring its strengths and weaknesses. Did you find any ?

[heartsucker]

Since you only have to recognize it, writing it down would probably be unnecessary. I don't know of any other such implementations.

[garrettr]

This is an interesting idea. We have higher priority things that we're focusing on right now, so I'm just leaving a few quick thoughts here:

1. First thought: how serious is this concern? Are there any known examples of such an attack occurring? In general, if I were an attacker, I would focus on compromising a server rather than individual source's accounts—much more bang for the buck. Likewise, as a defender, I would prefer to invest resources in protecting the server from compromise.
2. Requiring sources to remember a temporary codeword adds additional complexity for sources, and could make it harder for sources to correctly remember their secret phrase.
3. Adding a counter of source logins provides additional metadata about source behavior that is not currently being stored anywhere. Ideally we should seek to avoid adding (and reduce the existing set of) metadata about source behavior as much as possible, because any such metadata could be used in a leak investigation.

A journalist has no way of knowing that any messages were sent that did not originate from a true source.

Even if we implemented this proposal, this protection would be incomplete because it fails to protect against a malicious/compromised server performing a MITM attack. The only way to do that AFAIK would be to implement end-to-end encryption, which would require a complete re-architecture.

I don't know of any other such implementations.

This proposal reminds me of SiteKey, which was used by several large financial institutions but eventually abandoned due to its ineffectiveness.

[heartsucker]

From the SiteKey article:

A Harvard study[5] found SiteKey 97% ineffective. In practice, real people don't notice, or don't care, when the SiteKey is missing, according to their results.

This makes this proposal seem a lot let useful.

Anyway, to answer your questions.

First thought: how serious is this concern?

I don't know. This does solve the problem of being sent to the wrong onion site if an attacker can compromise the normal webserver that displays the non-onion landing page which seems somewhat more feasible than getting to the app server. Yes, bookmarks solve this some, but if someone is using Tails without persistence, that benefit is lost.

I would focus on compromising a server... Likewise, as a defender, I would prefer to invest resources in protecting the server from compromise.

Yes, this was more a food for thought post.

Requiring sources to remember a temporary codeword adds additional complexity for sources, and could make it harder for sources to correctly remember their secret phrase.

Also agreed. I figured this is where we'd ask a UX person if this is an acceptable workflow or not.

Adding a counter of source logins provides additional metadata about source behavior that is not currently being stored anywhere

I figure this one might be ok to add because it would likely be tied to the number of messages a user sent, so not much more information would be gained from compromising the DB.

[garrettr]

Yes, this was more a food for thought post.

I agree it's got some potential! I'm going to schedule it for a milestone after the upcoming release so we remember to revisit it at a later date 😄 .

[ninavizz]

I am very curious now having seen this, if this might come-up in Source user testing. :)