Hi Georg, 2017-04-27 18:46 GMT+02:00 Georg Lukas <[email protected]>:
> > The 2 byte expiration date is encrypted using AES256-GCM using the 32 > > byte key and the 16 byte IV. > > What would be wrong with a truncated HMAC-SHA256(timestamp)? > > I don't see the need to add an IV to invitation links, and I'd rather > use an HMAC than something semi-hand-crafted. > As stated in MUC I'm fine with an HMAC. I guess I just didn't think this through and just wrote down what I implemented last night. This will also shorten the token I guess?! > > > * A server which is also in possession of the secret key (due to it being > > in the PEP node) can 'decrypt' the tokens and check if the expiration > date > > is >= NOW() and authenticate a subscription request on the users behalf. > > That's a very elegant idea! > > > * A server which can do that should probably announce the pars namespace > on > > the account. > > Is there a specific need for that, except than to boost its compliance > ranking? ;-) > I think it might be useful for a client to know if they can rely on the server to dealwith the authentication or if they will have to do that themselves. > I see the UX problems, but I'm not sure if this is a good idea > security-wise. I'd like to hear other opinions on this. > > The pros of this approach are: > - a lifetime (24-72h) is a useful mitigation > - it doesn't matter if an attacker who got your token can subscribe to > your presence once or a thousand times > - pending subscriptions are a similar DoS in most clients as completed > subscriptions. > > The cons currently boil down to my gut feeling that limiting tokens to > "once" or "N times" with a small N is useful. > I guess in theory 'approving entities' can still do a rate limiting on the tokens? However I would find it very hard to come up with a good N that both works (me showing my QR code at a party to a bunch of people standing around me) and also prevents annoying DOS attacks. In any case i don't think N should be configurable by the user. cheers Daniel
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
