Remember when I wrote about Primeauth the pretty promising and intresting authentication service? Well, to be honest, my trust in them dropped a bit.
What happened? Well, let’s start from the beginning.
Primeauth started off mainly with it’s email and app-based sign in services, which were fairly simple and straightforward and trying to somehow being able to inherit the “magic” clef did to 2FA. Although their email and app-based offerings weren’t too bad, their stated main objective is something else. They want to make 2FA as simple as possible and apparently made a Key typing behavior way of signing in, meaning signing in securely without the hassle of normal possession-based 2FA or the requirement of sensors like the usual biometric authentication.
I certainly had my doubts into that from the beginning especially considering privacy, security and other factors, and well While I can’t say the doubts were true or false, I certainly can say that it’s not wise to to use this and the way they made this certainly isnt that worthy of attaining any trust.
let’s start from the docs:
the embed tags are made as HTTP. Even with SRI (Subresource Integrity, the admin places a checksum of an external file to load onto the site code, why that’s important is listed below) in place, others can certainly see that someone is trying to load the keyauth (as they call it) script.
Andone who knows even a little bit about web security should know that ANY page that contain private data like passwords should be locked down with HTTPS, and anyone who knoows browsers should know that browsers are deely against mixed content and while images usually just throw warnings, scripts, CSS and other “active” content gets immediately ignored without even trying to load them.
And from there it gets worse.
after setting up a local testbed and fixing the js tag, it didn’t work. quick as always, Surya, the CEO of Primeauth answered that I should reload because something is probably wrong with JQuery, I kinda thought “what JQuery, I don’t use JQuery”, as my testbeds are usually stripped down to the bare minimum for easier debugging and less distraction. So I went and checked the docs and told him that there was no mention of JQuery anywhere. Slightly annoyed, I got myself the embed tags for JQuery and tried again.
Now the adblocker of opera immediately went down and killed something. nothing too weird, but still a problem for the vast amount of people who run ad and/or tracking blockers.
And pretty much enough of the other tries of obfucation get obliterated quickly enough by using a beautifier like jsbeautifier.org, to crown the whole hilariousness, you can throw the script into the beautifier and THEN into the compressor to achieve a size loss of over 50% for the whole script, which axes the array as a whole quickly right into oblivion, gives the thing a bit more structure and probably also speeds it up with a lot less array accesses and other roundabout ways of obfuscation.
and while I certainly lost my smile during the stage it isn’t over yet, FAR FROM THAT. after tidying up the array I saw something they probably didn’t want me to see (especially after I told them so hard to include SRI. When I found 3 urls and each one of them had .js at the end, I kinda wasnt surprised after what I have seen but I definitely was not happy, especially after reading through the beautified version that each one of these 3 scripts comes from a different source and is NOT secured by SRI.
At this point I got mad.
I mean seriously, I made sure to tell him that SRI is very important for any security related script, especially if it comes from a different source and has access to the password field.
The 3 scripts come from Rawgit (CDN for github stuff), Cloudflare and Primeauth’s own website.
While these 3 scripts are HTTPS’ed, any one of those 3 can technically do a swap-the-script attack, and while I dont think Primeauth would do that maliciously, but there are at least 4 entities involved as potential points of failure: Primauth’s web hoster/server, Github, Rawgit and cloudflare.
if one of these is either hit by a hacker, does something bad on purpose, or the authorities are trying to make them do ugly stuff to get the users’ data, the user is screwed devastatingly.
That’s exactly why things like SRI are important. The page owner can actually check the files (even if primeauth tries to make it harder than needed) and quite literally give his seal of approval with the hash (basically an oversized and really secure checksum) of the file in your website code and if someone tries to break that seal by changing the file, any half-decent modern browser will know and wont let that script execute.
well primeauth certainly wipes out any of the benefits of SRI. the thng loads more scripts and with obfuscation the user cant properly check the files for their well-being, so far so bad.
but how do people in bad teleshopping shows love to say:
BUT WAIT, THERE’S MORE!
while the results are already terrifyingly, uh, terrifying, we have more snake oil.
Of course including totally futile and annoying disctractions like 4 (probably fake) tokens all assigned to the value “lol” (I would love to say that I am joking, but I am not, I found 9 occations of lol or LOL in the beautified script) and a symmetric encryption (I think anyone who knows about the topic knows where this is going) with a STATIC KEY and then also taking the time to DIY-build a JSON array by adding string parts together and renaming the parts of the crypto json (the code shows pretty much that the crypto function already outputs a nice json array). You don’t have to be a crypto researcher to know that this is BAD. doing bad crypto is one thing but trying to obfuscate that fact is a severe issue.
Well to conclude this, I think it is obvious that Keyauth should not be used by anyone until this is fixed. The only thing more intresting than my amateurish analysis would be a serious analysis by a serious security researcher who knows his stuff.