welcome back to our last talk of the day
another person joining us all the way
from germany
uh marcus
marcus works as
marcus works as the team lead and staff
engineer at microbiolytics he became a
django core contributor in early 2015
and served as a member of the django
technical board for the 3.x release
series
marcus is a member of the django
security and operations team as well as
organizer of djangocon conferences
good morning everybody thanks for having
me
and well it's still early so i figured
i'll do a bit of a pre-recording so you
can enjoy
my past self now thank you
hello and welcome to my talk on
authentication and identification
processes
some of you may know me from my
engagement in the django project
historically i've primarily contributed
to django's migration system
over time my focus shifted to organizing
some djangocons in europe and australia
as well as being a member of its
operations and security teams
in my day job
i'm a staff engineer and team lead at
microbiologics and responsible for our
cloud infrastructure and software
at microbiologics we build hardware and
software to analyze chemical liquids
and try to revolutionize and modernize
the industry in the context of industry
4.0
we are also hiring within europe for
python django
csharp.net
and typescript angular
as well as numerous other positions
when we talk about identification and
authentication systems
in the world of computers and our
society
we also have to look at what was there
in the centuries in millennia before
for thousands of years people needed to
identify themselves towards others
be it to show they are from the same or
a befriended tribe
be it that they had a certain status
within a tribe
or be it that they hold a certain
profession
as you can imagine over the years humans
came up with all kinds of ways to
accomplish that
it all started about 100 000 years ago
in south africa algeria and israel
people used beets and shells as jewelry
ash cool or the skull cave
is a prehistoric cave site
about 20 kilometers south of the city of
haifa israel and about three kilometers
from the mediterranean sea
the shells that archaeologists found
there
date back 75 000 years
each shell found at escuel
had a hole on the back most likely made
by humans
archaeologists believe that they
indicate social
a martial status
but there is more to that
this finding shows that cultures and
societies exist
for much much longer than expected
when we travel ahead in time and get to
the yield 3800 bc
we at the time of the babylonian empire
they were the first to do something
you're just too familiar with in
australia
the babylonians ran a census and
collected its citizens personal
information
every six to seven years
they did so to estimate how much food
they needed to feed the population
the egyptians ran seven censuses 1500
years later
they leveraged the numbers about their
population
to determine who would get how much land
after the annual flooding of the
nil censuses continued across various
empires and civilizations
the persians the greeks the romans
all the way to where we are now
historically people needed only to state
their name and profession
and possibly their parents names and
relatives
nowadays it either happens online using
codes sent via paper mail
or by statisticians going from door to
door collecting information
and estimating the total population of a
country
moving from the emea region to apec
another form of identification has been
common among the maori the indigenous
people of new zealand
in their culture
the head is considered the most
important part of the body
their facial tattoos tamoko
represent and indicate a certain status
rank anchors tree and abilities
it's thus unique to each individual
the tattoos are made by using sharp bone
chisels
to cut the design into the skin
suit-based pigments would then be put
into the open wounds
the wounds would heal over and seal in
the design
while the tamoko covered most parts of
maori men's faces maori women usually
had the tamoco only around mouth and
nose
they also are served a different purpose
preventing the skin to become wrinkled
in 1829 the british parliament started
to place more emphasis on printed police
records
with that
data could be stored in a personal
document
and linked back to individuals
this is the direct predecessor to what
we have these days to identify people
government issued id cards and passports
29 years later in 1858
sir william herschel
made a biometric breakthrough
hexa6 successfully implemented ink
fingerprints as manual signatures on
wilts and deeds
making it a means of precise
identification
this practice evolved into scotland
yards fingerprint classification system
and would later be automated by the
japanese
and further improved by the americans
all these approaches have something in
common
they work offline and identify a person
towards another person
from shells over tattoos to id cards and
fingerprints
when you know how to read them
you can determine information about the
person wearing or carrying it
but we are at an i.t conference so
people-to-people identification is less
of our concern today
i mean sure
when we're back at the face-to-face
conference eventually
we should be able to identify ourselves
again
which as far as i remember works by
either stating one's name or by
remembering somebody else's face and
associating it with a name
it's the people to machine
machine to people and machine to machine
identification
that we are mostly concerned about in
this talk
usernames and passwords
are the core of how we identify
ourselves towards computers
coincidentally passwords have a deep
historic background as well
back into the roman military while
called watchwords
they allowed a tribune
to find which maniple under his command
was not reporting back within due time
variations of username and password
include email and password or id number
and password
when implementing password-based
authentication
it's vital to ensure to never store the
clear text password
doing so can easily be considered
grossly negligent
it's also important to remember to never
encrypt a password but to hash it
the difference between encryption and
hashing is vital to the
security of a system
an encrypted password
can be decrypted and thus converted back
into its clear text form
a hashed password
on the other hand cannot be returned
into its clear text form
that is
when using modern cryptographic hash
functions
and also ignoring quantum computing
historically hash functions like md4 md5
sha1 and plainchart2
were used to hash passwords on a server
while secure at the time of their design
they have shown their weaknesses and
some are formally broken
so called rainbow tables
and simple brute forcing can be used to
unhash a password
over time a process called password
sorting was developed
in addition to a user supplied password
a random string called the sold
is added
for security the sort must be different
for each password
otherwise it doesn't provide much
benefit
compared to not having assault at all
salting makes the use of rainbow tables
pretty much infeasible
however specialized hardware
with the focus on parallel processing of
the same operation
can still create and compare millions of
password hashes per second
leaving the brute force attack vector
unmitigated
algorithms such as bcrypt airscript and
argon2
have been developed to make brute
forcing those password hashes
significantly harder
while bcrypt tries to solve the problem
by solely adding a cost factor to be
increased over time
script requires a huge amount of memory
to work
this makes using it in highly
parallelized hardware infeasible
when it comes to implementing script and
argon 2 in python
python has us covered
what we have here are two snippets one
implementing the hashing using script
the other one using argon 2.
script is part of python standard
library
and doesn't need any additional
libraries
whereas argon 2 depends on the argon 2
cffi library
the downside of script the way it's
implemented
is the lack of encoding the hashes setup
when you look at the argon 2 hash
you see various options encoded in the
string
from the hash name of the time cost
factor the parallelization and the
maximum memory cost
for ascript you're on your own to encode
and store those parameters
when you use django you can use the
build in argon 2 password hasher or
ascript password hasher
everything till here is pretty much
standard and likely and hopefully known
to most of you
but what else is out there
rfcs 2069 2617
and
7617
defined two authentication approaches
called digist authentication and basic
authentication
have been standardized since 1997 and
1999 respectively
because of this
pretty much every web server out there
can technically perform those
authentication methods
nowadays basic authentication tends to
be more common since it's easier to
perform and doesn't require to store the
password in clear text on the server
basic authentication works by having the
server reply with a www authenticate
header to a request
instead of delivering its content
browsers will then ask the user for
username and password
once entered the browser will resubmit
the initial request
and send the authorization header along
the content after the basic part is a
base64 encoding of the username and
password joined by a colon
i'll leave it as an exercise to you
to tell me the username and password for
this request here
as you can easily realize if a
connection between a client and server
is not secure
a man in the middle attack can easily
leak a username and password
as noted the problem with basic
authentication is the potential leaking
of user passwords
since they are sent over the wire or air
additionally with the rise of apis it's
not only people identifying with a
machine anymore
but also machines talking to each other
often on behalf of a specific user
but not necessarily
to solve those issues
token authentication was invented
tokens are typically mostly random bytes
encoded in hex or base64.
token authentication works similarly to
basic authentication
except that the client sends the token
along right away
instead of waiting for the server to ask
for it
instead of the basic keyword to identify
the type of authentication
token is used
it's important to know that such tokens
automatically identify and authenticate
a request
while man in the middle attacks are
still possible
tokens usually don't grant access to the
whole account
but only a subset of features
which means that an attacker might be
able to read some user data
but not right
in the case of services acting on behalf
of a user
those tokens are often called personal
access tokens or paths
in march 2021
github introduced an update to their
tokens
following a schema that was previously
implemented by stripe and slack
tokens now contain a prefix
similarly tokens to authenticate against
pipi the python package index
also contain a prefix
these prefixes don't provide any
additional security
but they allow easier detection of
secrets in code bases
by using a feature called secret
scanning
very similar
to the just expand token authentication
is the bearer authentication
it stems from the oauth
authentication flow
oauth provides a method for clients to
access a protected resource
on behalf of a resource owner
in the general case before a client can
access a protected resource
it must first obtain an authorization
grant from the resource owner
it then exchanges the grant for an
access
token the access token represents the
grant's scope duration and other
attributes
the client accesses the protected
resource by presenting the access token
to the resource server
in some cases a client can directly
present its own credentials to the
authorization server to obtain an access
token without having to first obtain an
authorization grant from the resource
owner
a bearer style authentication has a huge
benefit over all previous authentication
methods
the password or the secret that is used
for the authentication
never leaves the client
instead in the case at hand the secret
is used to sign a javascript web token
if the jwt
includes a nonce or a short lift
a man in the middle attack might be able
to read the token
but since it expires shortly after or
can only be used once
the attacker can often only do limited
things with those tokens
a similar approach was developed by aws
to access the apis
in aws's hmac based approach
the aws secret access key
is used to sign certain header values
and the aws access key id
since i just mentioned jwts and because
i know how popular they are
i want to echo numerous concerns and
issues around them
graciously provided by james bennett a
long and well-known member of django's
security team
in short jwts are over complex and put
too much power in an attacker's hands
there are too many knobs and variations
that give an attacker too much control
jwts can be signed or not jw keys can be
encrypted or not
the details of the signing or
encryptions are encoded as part of the
jwt itself
and while ssl and tls have learned the
hard way how to do or rather not to do
cipher of the negotiation
jwt did not learn
and when five libraries all make the
same implementation mistake it's rather
hard to argue it's bad programming
it's more likely that the specification
did a bad job of making sure people
avoid a certain vulnerability
so
stop using jwts
okay what else can you use
well
if you want to stick to json encoding
how about to use json dumps pass it
through base64 and then the page append
in hmac
turns out you can do that in six line of
python
sure you use the flexibility to choose
the signing algorithm
but that's exactly the point
there's no way for an attacker to
negotiate you down to a hash algorithm
that's less secure than shard 256
if you're using django just use django
core signing which implements something
like this just a bit more flexible and
reliably
okay after this xcourse and rant on
jbwts let's continue
on the note of public key cryptography
i want to mention mutual authentication
most widely known is probably ssh using
ssh keys
a client's public key is put on a target
server and during the connection process
the server sends an encrypted and signed
message to the client who verifies the
server authenticity
and sends an encrypted and signed
message back
that message can be used by the server
to authenticate the client
less well known as mtls or mutual tls
while typical tls only provides the
authenticity
of a server to a client
mtls also provides the authenticity of a
client to a server
however since the process is not
particularly user friendly
it's less often seen in user
applications
given the added security however it's
mostly used in corporate environments in
situations where servers talk to each
other and the so-called zero trust
network is present
while these public key cryptography
approaches have a significant benefit
or avoid user passwords
they still suffer from potential problem
the private key could be leaked on the
client side
due to male wear or rootkits
three years ago a new kid joined the
authentication party
and moved the private keys off of the
hardware that is used by a user to log
into a service
fido 2 is a standard by the fido
alliance and was first developed and
released in 2019
it defines the web auth and w3c
specification for using public key
cryptography to authenticate towards a
web service
the goal is to reduce the amount of
passwords used to authenticate on the
map
and thus make hacking accounts
significantly harder
i won't go into the details of the web
of inflow
but as briefly mentioned
the important part is the authenticator
this can be a device like a usb dongle
or an nfc device
something that's separate from the
device that the user wants to log in on
by having the keys on a dedicated
hardware
that they never leave
there's no way for the secret key
to be leaked
probably most notable in this field are
ub keys
the browser asks the user to insert it
and confirm
that they want to perform a certain
operation
by touching its metal sensor
the usb key then signs a server
challenge and provides its back to the
browser who sends back to the server
who now can authenticate this user
so where does it leave us
with it leaves us with loads of ways for
users and services to identify
themselves and to authenticate each
other
i talked about the good old password
authentication
which has accompanied us ever since the
internet exists
it certainly solves its purpose
but it's far from ideal
every so often services get hacked and
user data including their passwords is
leaked
we are lucky when the service used to
stop a strong and modern hash method
it didn't stop passwords in clear text
we talked about token authentication
which is ideal for services
to service authentication
and identification in a trusted network
however if the network isn't trusted
something stronger might be required
pre-shared keys like the aws credentials
or client id and client secret in the
oauth process can reduce the problem of
key leakage
by using signatures for authentication
public key cryptography can be used for
authentication without the need to share
the secret upfront
and lastly
physical hardware such as ub keys or
other types of hardware security modules
can move the cryptographic operations of
the normal hardware into specific
hardware that keeps the secret keys safe
with that i want to thank the organizers
for the snake oil academy 2021 and pycon
australia 2021 for yet another well
organized event
i want to thank all of you for tuning in
and i hope you learned something
and lastly
i want to credit some sites that
provided quite some useful information
especially with regards to the historic
events
thank you
thank you very much marcus and thanks
for joining us at uh
i'm not even going to pretend i know the
time i should have asked while we were
talking
it's 9 27 in the morning now
this is not too bad this is all right
it's not it's not unless we get up in
the middle of the night to watch other
talks and then go back to sleep
which probably should have not done
and watch the recordings later
right we have one very important
question for you
tom would like to know if you've just
told him to roll his own crypto
well
um
everybody who wants to roll their own
crypto should um figure out um if that
is really a good idea and if they um
make the right life choices there
um
generally now please do not roll their
own crypto but rolling your own crypto
doesn't necessarily mean
that or
appending a signature to some blob of
data isn't particularly rolling your own
crypto from my perspective running your
own crypto is when you go and implement
sha-256 or as yourself like implement
the underlying cryptographic algorithms
that is something that you absolutely
should not do just don't the moment
where you go and do that
um
you probably do that because you started
building your own programming language
and can't use and can't rely on anything
else but also then it's probably
something you should
probably don't want to do
um like yeah don't don't write your own
crypto by depending a signature based on
proper
proper improperly implemented methods is
absolutely fine
so try it carefully then
yes yes please
uh it's fantastic to have you here again
uh closing up the uh the day for us
um we'll be back in a couple of minutes
to give a quick wrap-up to the day uh so
we'll see you all shortly thank you
thank you