There is an alternative method to achieve similar results using very high frequency (40khz in the case of the video below) audio as a carrier for audio that is within the human range. It modulates the amplitude of the carrier signal (in the same way that AM radio does). The high frequency audio interacts with surfaces it hits and kind 'self decodes' into human-perceivable audio. It's doable by DIYers with a little electronics knowledge, too!
Ironically, at the time of landing, there was no live coverage on the state media CCTV's news channel. Instead, it was covering the story of Utlima Thule.
Also you should know that the launch/landing window of a lunar mission does not occur everyday. And it's predetermined by orbital mechanics.
Out top of my head: It could be used as the payload for some serious cyber attacks. Imagining the mass panic it would cause, if it was to be played on every TV across the country for real.
This kind of attacks are hard to pull off and one'll have to nail it on the first try. It would be sad for the hackers, if they failed because of a poorly made fake news video.
My question is: how practical would it be to use a 1TB RSA key for average users? I assume that the size of cipher text would be somewhat depended on secret size.
The storage space and network bandwidth is not free.
I don't see any valid arguments in the post. The issues raised are either mis-implementation or misuse of JWT.
All I am getting is "JWT can be misused in such such way that makes your application vulnerable. And neither its standards nor libraries prevent that, so it sucks".
But when is the last time we see any technology successfully prevented people from being silly?
> But when is the last time we see any technology successfully prevented people from being silly?
You can never stop someone sufficiently motivated to shoot himself in the foot from doing it. But you can make it harder for those who would do it be accident by providing more safety features - in case of security this is usually seen as a good idea (safe defaults etc.)
But this is the biggest thing with any security-sensitive code or practice!
Do not give people options, do not allow algorithmic flexibility, do not have fallbacks, do not have backward compatibility, do not allow "testing" or "insecure" options, do not have complex state machine behavior.
All of these things are exactly what JWT or other "design by commission" standards like SSL suffer from and they have predictably lead to ongoing, at times unfixable security problems.
You shouldn't. Simply check that the hash algorithm specified by the client is the one you used when issuing the token. In a side project, I simply hard code the algorithm [1].
Yep. Revocation is tricky with JWT, but it's not that bad.
The expectation should be reduce in database io, not getting rid of it entirely.
Overall you could issue tokens with short lifespan, say 5 minutes. And having the client refreshing tokens periodically. Reading database every 5 min is certainly an improvement over reading it on every API call.
You could also only check revocation table if the performed operation is security-critical or sensitive enough. I wouldn't care if the user is trying to perform a read-only operation on some public data with a revoked token that is going to expire in a few minutes anyway.
>3. No way to revoke all of one user's tokens because there is no list of those tokens
I don't see why one would not maintain such a list, since generally issuing a token requires database io anyway. Storing a token when issued is just one additional write op.
This reminds me of Peter Watts's novel <Blindsight>. Two captured "Scramblers" (the highly intelligent alien without self-consciousness) managed to communicate with each other in a way defying all human analysis, even with human knowing what they are saying (the plain text).
I imagine you can certainly drive people crazy with this thing. For some one who doesn't know this kind of technology's existence, it's pure magic.