Primeauth - Good or Not?

Hi everyone, it's me again. (well who else should it be 🙂 )

a while ago I finally recieved my beta invite for Primeauth, so I'll have to lose some words for it.

To start off, this is NOT an advertisement (and I certainly have enough rant material below), I am NOT getting paid for this or recieving anything for this post, these are just my thoughts of this intresting new piece of Auth, that seemingly wants to replace Clef which sadly going in just a bit more than a month.

To give you the short version before (it's probably going technical below) and well it is in beta and it's far from perfect but it doesnt work bad.

well now we get to the Intresting part.

I first heard about them when Clef wrote their Blogpost, Primeauth people kind of promoted themselves as a possible alternative.

I pretty much quicky read about it, and threw them a bunch of mails surrounding things I am curious or worried about and their answers were intresting to say the least, although of course people can say a lot of stuff when the day is long (and I think the day is surely longer in India rather than here in Germany, although, with summer approaching way too quick for my taste, days are getting longer here as well, but I digress).

Well the best way to get to know something is to actually try it out, so I signed up for this little piece of fun. Certainly took a while but well, I am in by now. So let's go though the stages you'll experience when working

Step 1: Securing the Primeauth account

Let's start off with the positive things first. They do not store any passwords for signing into their customer panel. They use Magic Link Sign On (MLS), which, long story short, works like Medium. If you have never been there, it's essentially just you entering your email address, and they send you a link to sign in. The best thing of this is that the user doesnt have to rely on the Website to implement 2 Factor auth or any other high security concepts, because this all can be made in your Mail Account, and the tinfoil-hatted user can set up his own domain with email server and address including "paranoid"-level security.

Step 2: Login Methods for the Website User

They also offer a simple app based accept/reject based sign in where the user just has to do a tap in the app or the notification, (by the way, PIN Support is on the way for a two factor experience) a QR Code based Sign-in, which doesnt work yet on the App-side and the "Key Typing Behavior", which certainly sounds kinda scary, but long story short they use a Javascript to analyze how you type your password and give a confidence value upon that which the server may use to trigger a more "normal" second factor authentication (key behavior is 2FA after all, you have your password as what you know, or knowledge and the behavior as what you are, or biometry) like app signin or MLS. which certainly might be needed for example in case you change devices, I mean every keyboard feels different and even on the same device if you for example type numbers for the PW on the num block and while you type your password you notice numlock is off, delete parts of the passwords or insert numbers afterwards, the whole telemetry is going down the drain. although to be brutally honest, even though the Idea is nice, simple and frictionless for the average user, there are problems: 1) we have to deal with Javascript. meaning you can immediately forget going in with noscript, then we have the fun of having telemetry about your password sent to a 3rd party, and even if they are diligent about not being evil about it, if it get's hacked (I don't think I need to explain Murphy's Law at this point) you are really screwed. I dont really know whether you can hash or otherwise trapdoor-function behavior data and still be able to get approximates, but it is a wise idea to assume you can't just to be safe. meaning with this data anyone could let a software imitate how you enter your password, which is GOD. DAMN. TERRIFYING!
overblown youtube quotes aside, while the other APIs still require trust to a 3rd party I think it's a lot less terrifying to have MLS or App/QR Signin, because that actually cant be any worse that using for example Social Sign-In like over Facebook, Google or whatever.

Step 3: Behind the Scenes

once you get into their customer control panel, you can immediately see that the stuff is still being made, it is a beta after all. quite a few pages in the docs are still blank and some things aren't implemented yet.

And to top it off, some parts of the APIs made NO. GOD. DAMN. SENSE. (I admit I have been watching too much "The SCIENCE" lately) I mean the names changed all over the place. of course there are some things that don't change like that you have your "token" and "secret" as the authentication values of your Application, BUT, now we get to the good stuff. when doing App Auth or MLS you got back an identifying value, which is oh so conveniently (attention to other aspergers like me, sarsasm is in action) also called "token" but you had to return them as "id" or "mls_token" respectively while the QR API returned a code which is sent back as id, see, in no case the name of the Identifier stayed the same and it was far from over, each API had different required values and stuff even though it's not really needed. for checking the App Auth you sent over the ID, token and secret, fair enough. as result you got back the accept status and if accepted the email. for checking up MLS you have you had to send the email address AGAIN (after you already sent it for requesting the MLS sign in) and for QR you got the email returned but didn't have to send it even once (well there is's no surprise, because that's the point of a QR Code the person has to scan by him/herself and doesnt have to enter anything on the website to start).

BUT: now we get to the good stuff, see I spoke in past tense, and that not without reason.

On their Support line I always had the CEO in person, which is kinda awesome but also helps since we dont have the sometimes seemingly stupid level 1 support with "did you try turning it off and on again" or whatever. He (or she, I have no Idea of Indian names) provided a really good support and is really quick on the uptake, for example when I explained that QR has a problem that the just accepting it without asking, allowing for easy phishing, he pretty much instantly got what I meant and said that they already had iit on plan but move it up on the priorities. Also they made many API changes which made this thing make a lot more sense in the end. now you have "id" as the unique id for the authentication in all cases, making it a LOT less messier and a lot more consistent. it also doesnt ask again for the email on MLS, also meaning that if you use redirect URLs that you dont have the potential privacy issue of you mail being iside it and listed in your browser history.

there are still a few things that could be made better (like an explicit answer for a rejected authentication when using the app based auth. meaning that if a website auto-refreshes until an answer (like primeauth's WordPress plugin does) which is bad for the server and also for the API (until we get webhooks).

also they are really quick in resolving problems like when I triggered another Error 500 because I was stupid enough to forget to insert the API keys after downloading from git.

Step 4: Doing the API

Actually doing the API was surprisingly simple, you just setup a post with the needed values and get a JSON back. the only real trap in PHP is that if you use cURL is that you have to set up a CA Storage, which isnt hard, but if you dont let cURL give you the error, you won't see it, because PHP wont just die from a dead cURL call (which actually is a good thing, because file_get_contents, which does kill the script with an error message, may leak information you dont want to leak, with cURL you can just quietly log them.)
For me it was even easier since I just forked the cURL calls from an oAuth Implementation I did a while ago, and bluntly, this thing is really easy especially compared to Twitter's authentication which needs THREE HMAC-SIGNED API CALLS (where everything is signed from API-URL to time and parameters, and since they use POST it even includes a complicated building mechanism) to get in, primeauth needs 2 calls but only because you dont have to redirect the user to their site. Google for example just needs one API call after he returns from the Google oAuth Page to yours to return the code for a JWT, and that without any signatures and stuff. (I do think the signatures arent a bad Idea since the API Secrets arent floating around the Internet, but that doesnt change that it's really complicated, especially considering you have 5 values (your application key and secret, the token and secret of the authentication and a token verifier) to juggle around for the login instead of just 3 which would be normal (2 application keys and the Authentication ID/token/whatever)

Enough ranting about Twitter and back to topic.
Building up the PHP was relatively easy for a testbed, and I am making everything open source, just for the sake of it, but this is still just the testbed, proper functions for website implementation are in progress.

Step 5: Primeauth as a User

well from a user side it's pretty easy. mail auth is stupidly easy. you just get an email, click the link and you are in. how the website gets your email address is something that depends for them, they may ask for a username and get your mail from the database or they just ask for your email directly, but essentially everything on that part is up to the site, it's for example fairly easy to use this as second-step authentication after you enter your password, so that you are not immediately screwed if your mail account is at least decently secured.

App and QR auth are fairly similar in the fact that you need to setup the app first. You need to verify your email and/or mobile phone number, which you can both use for authentication if you like.

after that it's fairly easy for both of them, for the App-Request Auth (as I like to call it since the App requests you to accept or reject) it's a bit easier but the website has to identify you first, as a second step auth it's a lot easier but as a first step or only auth, QR is easier in my opinion.

for the QR you just open the app and select scan QR and select under which Identity (phone number or email address) you want to submit, and then you just scan the QR Code (later you'll have to accept/reject first so you know what you are authenticating for, but that's a good thing) and the website will have your Identity then after the scan.

so the Action-based Methods (where you have to actively do something) are fairly easy but we have have the TERRIFYING and pretty controversial typing behavior based auth (called Keyauth) as well.

the script senses how the user types (but seemingly not what the user types, but it would be possible and the user cant see it, so it would be best to use junk passwords if you know that there are things like that on the website. because if Primeauth or a CDN they use to distribute or something along those lines gets hacked you can be sure that your password has been compromised and better change it soon.
Anyway, after typing and submitting, the website can see how confident Primeauth is and request a second step if it isnt confident enough. How Confident primeauth has to be is actually something the website can set because they dont get a true/false, but instead a percentage, meaning websites can be loose or strict as they like.

(Not so) Final Verdict

of course this thing is still in beta, so I can't really push a truly final verdict but at leastthe state it is in and the development has been very promising, and while I certainly dont like Keyauth, the other things are pretty thought out and work pretty good for a beta.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.