Visual representation of key in authorisation requests about unilogin HOT 15 CLOSED

No, it is rather a malicious gas relayer. Currently pending authorisations are stored in the gas relayers (#156) - so a malicious gas relayer could substitute their own key in the authorisation request.
I imagine any off chain storage for pending authorisations would be susceptible to the same.

from unilogin.

If I understand correctly each device has its own key, and if you use blockie to visually represent this new device adding, this would create a confusion for the user, as he will see 2 blockies, the one on the top the ID/ENS and now new one the new device confirmation.

I agree with Alex, a picto-string (or emoji-like) casual visual checksumming is a superior solution for such use cases, and work the same as One-Time Password combating man-in-the-middle attacks. I don't have any emperical study to back this claim but i'm working on one ;)

Q. How can we implement that with UniversalLogin?

Emoji: Like Radix-emoji, Ecoji or Base Emoji very straightforward base-conversion, further

1. Non use filtered set of emojies, and there are a lot of very similar Emojis already.
2. Emojis aren't consistent across devices and platforms, and could look completely different,

You can solve that by shipping all Emojies used a couple of hundreds up to 2000+ depending on the approach we're taking.

Momcode
they are basically 16 to 32 easily recognized colorful pictograph like heart, square, star, triangle etc.. like
or

check out https://momcode.io/lab/

the downside is that they aren't as beautiful as Emojis, from the other side, they are consistent across devices as it's only up to 32 pictos on svg come part of the library.

btw there is a Emoji set at Momcode but it's not any better than Ecoji & Base-Emoji above (just smaller set of 256)

attack, collision and possible values
using a pool of 1000 emojis as Ecoji, with 4 of them we have 1+ trillion possible combinations. (1000^4)
using a pool of 32 Momcode picto, with 4 of them we have 400+ billion, and with 5 pictos it's 1+ trillion (32*8 colors^5)

actually, the possible combination above isn't the indication for collision probability, due to the birthday paradox. but still this good enough..

from unilogin.

Thank you. But we should discuss other solutions for the same problem: could you use a PIN code instead, so that a malicious actor cannot send authorizations? Or maybe use something other than blockies (some apps use a 4 emoji check)

from unilogin.

The problem with a PIN code is that the malicious actor could still swap in their own key under the code. Hence why a visual representation of the key works, agree that blockies may not be the best way - 4 emojis sounds promising.

from unilogin.

Wait, what is the threat model here? Is the malicious attacker in control of the interface code? Because then they can also show the incorrect blockie.

from unilogin.

Valid attack vector, and it's interesting because even if we had pins or other identifying information like IP, the attacker can still use the same.

I wonder if that;'s not a case in which emojis would be more interesting to use:

from unilogin.

Pinging @drhus for his work on emojicode

from unilogin.

Pinging @tkali

from unilogin.

Some feedback and ideas on this debate. First, thanks for the PR, @gtlewis. If anyone is curious to what it looks like, here it is:

As I said before, I don't want to overextend the usage of blockies. I see no reason the user needs to know or understand the key they have on their device, so if it's simply about comparing something with the other, we could pretty much use emojis as a more friendly thing. Here's an example I sketched, using MomCode's selection of symbols:

The problem, of course, might be that the person will overlook and not really compare the two symbols. If that's the case, we could even improve the interface by requesting them to type the symbols, by using a builtin javascript emoji picker (many open libraries out there):

This however might be an overdoing it for such a screen. I think we could consider this as a pin code for even before requesting authorization, but then, it could be brute forced and if we are relying on brute force protection from spam, we might as well simply use a POW requirement.

from unilogin.

The emojis are nice - however thinking more about this:

I see no reason the user needs to know or understand the key they have on their device, so if it's simply about comparing something with the other

Actually I believe the visual verification does have to be derived from the public address/key - else a malicious gas relayer (or any malicious actor sending an authorisation request) can substitute their own key in the request. E.g. if request is sent to authorise 0x123... with symbols mouse/surprise/wind/elephant then a bogus request can be sent to authorise 0x666... also with the symbols mouse/surprise/wind/elephant. Deriving the symbols from the address/key requesting authorisation prevents this.

Of course it doesn't have to be blockies (the emojis are much nicer...) and user having to type the emjos is sound idea.

from unilogin.

There is several javascript emoji pickers (emoji keyboards) but this is going to be a pain really, very inconvenient for the user to select that 4 emojis out of thousands of emojis..

even if we use Momcode's keyboard (there is a simple keyboard module) it's going to be a pain still to find your emoji out of 256 ones

the symbols version is simpler however still a lot

ps. this last keyboard can be reduced by 80% by putting colors on tabs

While complete Momcode/Emojis keyboard can be inconvenient, we can alternatively

1) show the authorization pictos among 3x, allowing the user to select the 4 pictographs from 12 (so the keyboard would be the 12) ex.

2) or alternatively showing the same authorization 4 pictos on the remote device but in random order, user only need to sort out the order by dragging them right and left

Actually I believe the visual verification does have to be derived from the public address/key

I agree, but keeping in mind a malicious gas relayer can use a vanity address generator to generate an address which he control, that has the same 4 authorization picto/emojis we will need to have something more than 4 pictographs, i was thinking this 4 emoji would be represnting first 4 characters and last 4 characters of the Hex Address (plain deterministic encoding as Momcode), but brute forcing 4 bytes can be done with vanity generator with reasonably little time..

So we may need longer than 4 pictos, something at least > 6 bytes to be considered secure..

from unilogin.

Authorisation requests should expire (I e. dropped from the UI) after a period of time - say 15 minutes. So the question is how many attempts to create the same symbols can be made in 15 minutes. If
we think, say, 100million is enough combinations then 4 symbols with 100 in the set is adequate.

from unilogin.

There are two threat models that we need to address:

1. A malicious relayer sees a request and changes it to their own address
2. The relayer is honest, but an attacker is sending multiple auth requests trying to trick someone in authorizing the wrong one

To address (1) I would go with @drhus approach of showing 12 symbols, 4 correct and 8 random, and asks the user to put them in order. This is simply to guarantee that the key being added is the one they created on the other end. The requester shows the symbols, the authorizer inputs them.

To address (2) we could add an "emoji pin" in which we would invert the action and request the requester to type the pin in order to be able to make a request. This pin could be always the same, and the person can memorize (they can be reminded of it on their app) or it could be generated on the fly.

I like the solution to (2) but I feel that it adds a lot of complexity (although I do believe users are used to typing emojis so finding them won't be a burden) in the whole interaction for a problem that simply doesn't exist anymore and can be first addressed by rate limiting, or putting a captcha on the requester window.

Basically: I would add (1) as a solution first (but it's not urgent) and would consider (2) if other more basic spam protection fails, as I rather not need to add a pin right now.

from unilogin.

I would however add more than just the 256 selection you have shown. With that restricted set, 4 symbols represent the first 8 chars of an address, and that can be mined in a few seconds, while if we increase the symbol set to 1024, then 4 emojis represent 10 characters, which would take years in an average computer. We can even increase the security by picking 10 random characters from the address, instead of the first one. That almost for free, since the end user still only needs to pick the characters from a set of 12 symbols. Here's what a set of 32x32 symbols looks like (there are even more emoji than that, so we could even replace a few of the weirder ones)

*edit: striked out something that didn't make sense

from unilogin.

Implemented!

from unilogin.