Introduction to PASETO

hello everyone i'm dev lindelow i'm a software developer at nmeta and i'm here to talk about introduction to passato platform agnostic security tokens first of all i'd like to thank besides budapest for this opportunity i'll be uh sharing you this pasero okay so let's start so just to uh refresh our memory here's um jwt and some other things this is json web tokens you know it's our oh an open industry standard rfc 7519 method for representing claims securely between two parties right here's a sample uh token jelly belly token job token from jwt website so as you can see here it's divided into three there's the header payload and the signature so sub subject yap issue time

jwt is used today for securely exchange [Music] information between two servers and then also in a single page application authentication or spa or authorized operations across servers we have some acronyms here we have uh jose or jose javascript object signing and encryption also the name of the working group jose is actually a framework intended to provide a method to securely transfer claims between parties the next is the jot you know representing claims in compact and url safe means nexus we have jwe or the json web encryption which encrypts content you know and then jws which is the json web signature which secures content with digital signatures and then jwk is the json web key represents

keys used for signing and encryption and then we have gwa which is json web algorithm which is a cryptographic algorithm and identifiers use with all the above

and here we have supported algorithms we have hmac shop hs and then rsa plus shop rs we also have es256 which is a symmetric key cryptography algorithm electric curve digital signature algorithm and then some ps here so next is signing versus encryption uh encryption you know for unreadable data to unauthorize parties so perfect for confidentiality then we have signing here is for data integrity you know message authentication and reflection and you know for uh integrity in short and then multiple ways of signing with a secret uh using hmac that's one and then with a private key using rsa easy in others and some pointers here you know multiple systems can issue tokens a token can be used

by multiple systems all these systems can use different libraries now let's go to vulnerabilities and exploitation in chat or json web tokens first still the first uh vulnerability that can be found it's not checking the signature so some jwt or json web token libraries methods are decode and verify so the problem with you know with this code here is that this is what i used to happen before in in some cases that uh there was a bridge or something here jwt.decode instead of you know verifying it or gwt verify it's a big mistake here next is exploitation so how do you explain this get a token decode and then tamper with payload then send the token that's it easy

next vulnerability the non-algorithm here and i think i should use this one laser pointer yeah i think it's better the non-algorithm so used to be supported by default in few libraries basically don't sign the token and exploitation get a token decode the header and change the algorithm none or none decode and tamper with the payload and then keep or remove the signature that's it next is algorithm confusion h map rsa for instance the token has been signed using hmac instead of rsa you tell the receiver it's an hmac and it verifies it with the public key thinking it's rsa so this is the exploitation get a token sign with rsa decode the header and change the algorithm from rsa

to hmac then tamper with the payload lastly sign the token with the public rsa key easy kid parameter so uh kid is an optional header claim which holds a key identifier particularly useful when you have multiple keys to sign the tokens and you need to look up the right one to verify the signature this is done prior to the verification of the signature so what kind of exploitation can we do here get assigned token containing kit parameter decode the header and change the kit with sql injection payload then tamper with a payload lastly sign the token using the return value from the sql injection and that's it rim next is wikis so here's an example jwt sign with

hs256 any secret

sn1f exploitation get the jwt cracker it's available online and then from this code runtime get the wt crack and then followed by the token itself you'll get this secret it's too short that's why you can easily do this and there's more you know in like invalid curve attacks yeah so uh as you can see here developers need like me we need easy to use tools that don't open the door to a ton of attacks

there are a lot of ways for dwt's to go wrong big into the jose standards the jose uh jose you know advocate response to this criticism is use a specific library so this ships the blame into the library developers and the library users and it has industry anti-patterns like standard designers here let's give users a lot of choices it's not good right and then the advocates then blame the implementation rather than the standard and then the security experts just tell you declare standard harmful provide no alternative then we as developers roll our own crypto so yeah can you really blame the developers now we have here pasero platform agnostic security tokens so posero is everything you love about

hosting jwt kw e jws without any of the many design deficits that plague the jose standards that's good definition from the pasero website so here's an example of pasero token grab my laser so it's divided into three and four here version and then purples then payload and there's a optional footer which is an example a version here v1 or v2 and then local then the payload here up to here and then the filter so what is the version what does it do version tells you what version of pasero is being used with the token and if if v3 comes out a year from now then users would only be allowed to use v2 version 2 or version 3

but no longer version one let's go to the next one the purpose which is local the public diff or different types of pasero so local means um referred to as symmetric or shared key facets because that is the type of the cryptography that they use always encrypted and an attacker that was able to get a hold of the token will not be able to see the data inside unless he has a key and then the public both paseros are always signed but public is not encrypted so that's the second part of the token the purpose so here um next is what's inside the passato payload this is an example of poseta payload we have you know id here

email or permissions and here are the rest the payloads samples sub expiration issuers object audience variation not before issue that token id key id

and then the last part which is an optional footer it's a base64 url some people wants to do key rotation so um they would want an encrypted part of the local token they get stored like a key identifier that references a specific public key or specific secret and here are some placenta implementations i'm not sure if you can see it here so let's uh take a look in the list one by one we have for c language here then for elixir for go language for java de pasetto which you'll see it uh later javascript acetojs lua for net and node.js for php python will be ros and swift then its features

so a jwt versus uh pasetto um jwt here yes that's horror of knobs and levers and unauthenticated modes are available so json.tokens has a lot of options including often unauthenticated options right or spacero you have two options version and purpose everything is authenticated local tokens are always encrypted so that you don't actually uh click sensitive information for a local system so locate demo here i do this okay yeah so this is a java application and as you can see here we're importing jpacetto from here to here and now what does it do is it's just it's going to print some fields here so let's go to the top here all the way to the print line so yeah

shared secret keypair here's create token we have great token here then parse token result get claims get audience and also custom claim here total claims here's the implementation of the create token in the above it returns this passato version one um we have set shared secret here enter then set issued at set expiration set audience set issuer then claim and then make it compact i also have a parse token here from pasero um parts builder set shared secret set public key we have build here then return it so yeah and then search secret again required audience record issuer build so let's try to run this

so there you go there's the paseo token version one local then the payload yup over here we have token claims uh there is an audience and here's scott i don't know how to pronounce his name sorry um he's the the writer of pasero so says here's the at least some some list of cryptography designed for humans opinionated interfaces with few options now you should have an opinionated interface so here's we have encrypt and decrypt the encrypt here should be your api for any encryption library then users shouldn't ever need to even know what enough is to encrypt safely persian protocols with hard-coded cyber suites valid by cryptographers of course then logically separate symmetry cryptography from asymmetric

cryptography api should be simple and easy to understand and actually there's a lot more you should see uh his presentation video it's in the internet i would highly recommend you to watch it so yeah um thank you for listening that's uh an introduction to pasero hope you learned something okay i'm out thanks