Commit 48794aa
committed
feat(security): simplify decrypt error handling
Before this patch, when decrypting a value without using a password,
it would call `decryptWithoutSecret` with the system `secret` as
`password`. When this fails, it would retry with an empty string as
`password`.
This has the practical disadvantage that it can lead to confusing
error messages. For example, when using the TOTP app, when the system
`secret` is misconfigured, the first invocation will throw a sensible
`HMAC does not match.` error, but then it is retried and the retry
throws a `Hash_hkdf(): Argument nextcloud#2 ($key) cannot be empty` error
causing confusion (e.g.
https://help.nextcloud.com/t/hash-hkdf-argument-2-key-cannot-be-empty/192556).
Of course this fallback to using an empty string is likely part of
some sort of graceful migration from the days when the secret could
be empty (e.g. nextcloud#34012,
nextcloud#31499).
However, taking a wider perspective, such 'fallback logic' in
security-critical areas makes things more complex, which is a risk.
It's not quite the same scenario, but Heartbleed does come to mind.
For this reason, rather than a 'surgical' improvement for the particular
case encountered above (increasing complexity further), I think it'd be
worth to start considering removing this fallback entirely
(perhaps in v32.0.0?) - hence this conversation-starter PR.
Signed-off-by: Arnout Engelen <arnout@bzzt.net>1 parent 09411a1 commit 48794aa
1 file changed
Lines changed: 3 additions & 11 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
91 | 91 | | |
92 | 92 | | |
93 | 93 | | |
94 | | - | |
95 | | - | |
96 | | - | |
97 | | - | |
98 | | - | |
99 | | - | |
100 | | - | |
101 | | - | |
102 | | - | |
103 | | - | |
104 | | - | |
| 94 | + | |
| 95 | + | |
105 | 96 | | |
| 97 | + | |
106 | 98 | | |
107 | 99 | | |
108 | 100 | | |
| |||
0 commit comments