diff options
| author | Joey Hess <joeyh@joeyh.name> | 2015-05-13 14:22:08 -0400 |
|---|---|---|
| committer | Joey Hess <joeyh@joeyh.name> | 2015-05-13 14:22:08 -0400 |
| commit | 3575f939d8c836ac7d2b28f334bab6747cec5ec4 (patch) | |
| tree | 41a6f492ac25c7879c565c447afe680c72a79c0c /doc/todo | |
| parent | ccd285b9862e0d0090ba56287c6a22dc4900eecd (diff) | |
| download | ikiwiki-3575f939d8c836ac7d2b28f334bab6747cec5ec4.tar ikiwiki-3575f939d8c836ac7d2b28f334bab6747cec5ec4.tar.gz | |
update
Diffstat (limited to 'doc/todo')
| -rw-r--r-- | doc/todo/emailauth.mdwn | 7 |
1 files changed, 4 insertions, 3 deletions
diff --git a/doc/todo/emailauth.mdwn b/doc/todo/emailauth.mdwn index bd9428756..05b7f1177 100644 --- a/doc/todo/emailauth.mdwn +++ b/doc/todo/emailauth.mdwn @@ -31,13 +31,14 @@ A few points to make this more secure: Still, this could be attacked: * If an attacker can access a user's inbox, they can generate a new login - link, and log in as them. + link, and log in as them. They are probably busy draining their bank + account by this method and not logging into some wiki though. * If TLS is not used for the email transport, a MITM can snoop login links - and use them. + and use them. Again probably more lucrative ways to exploit such a MITM. * If https is not used for the login link, a MITM can intercept and proxy web traffic and either steal a copy of the cookie, or use the login link themselves without letting the user log in. This attack seems no - worse then using password authentication w/o https, and the solution is + worse than using password authentication w/o https, and the solution is of course https. * If an attacker wants to DOS a wiki, they can try to get its domain, IP, whatever blacklisted as a spam source. |