[riot-notifications] [RIOT-OS/RIOT] sys/shell: new module shell_lock (#13082)

chrysn notifications at github.com
Wed Nov 11 21:07:47 CET 2020

By authentication I just mean that the system knows that the user is who he claims to be; if there's only one user who has all rights (and not being that one gives you none), that's perfectly fine.

Yes, protecting different channels is hard, that's why there's different security protocols that address this for each of them, and that's why generic security protocols are complex. But splitting encryption from authentication isn't as easy as this approach makes it look: At the very least, it requires that the receiver of the credentials is authenticated. That's what's happening when a password is entered on an HTTPS website: It's OK because the client has ensured the server is who it claims to be, and over such a channel can then send the secret. It still has other downsides, which is why things all around are switching to 2FA, single sign-on and tokens, but that's the very minimum. For HTTPS we have the PKI that hopefully doesn't fail us, which is something unavailable for any transport I can see this used over.

With the concrete example of BLE, when encryption is enabled and it's used in Just Works mode, the connection can be intercepted, the password read and the device taken over. For OOB and Passkey methods, they already provide a pairing to the device that's being authenticated, and short of introducing multiple users, that in itself would IMO be sufficient authorization to use the shell.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/notifications/attachments/20201111/2c12dfcd/attachment-0001.htm>

More information about the notifications mailing list