Authentication defintion
RFC-4949: the process of verifying a claim that a system entity or system resource has a certain attribute value
Whatis.com: the process of determining whether someone or something is who or what it is declared to be
NIST: verifying the identity of a user, process, or device, often as a prerequisite to allowing access to resources in an information system.
What is important: these definitions mention authentication of an “actor” that could be anything, even not human (software component, hw element).
Shorthand for authentication is authN or AuthC, while AuthZ is for authorization.
Authentication factors
- Knowledge: something only the user knows (code, personal id, static pwd)
- risk: storage and demonstration/transmission (you need to show that you know it, so it can be stolen while you show it, and it’s stored somewhere)
- Ownership: something only the user posses ( often called authenticator) e.g. smart card, smartphone, token
- risk: authenticator can be infected with malware, or manufactured in a country that requires govt control.
- Inherence: something the user is (biometric characterstics)
- Risk: counterfeiting and privacy: cannot be replaced when “compromised”. For this reason they should be used only in very secure environments, tipically for local authentication, as a way to unlock a secret or a device.
Digital authentication model (NIST SP800.63B)
- Actor that wants to use system === applicant
- if applicant possesses authenticator can provided it to CSP, if can get one (e.g. smartcard)
- CSP: component that issue or enrol user credential and authenticator
- and verify and store associated attributes
- The actor becomes a subscriber once they have an authenticator.
- The Relying Party is an application that checks through the verifier if the user is valid.
User authentication flow
Password-based authentication
- secret = user password
- client sends password in cleartext
- server verifies the proof:
- 1: knows all passwords in clear text (f = i(identity control))
- 2: knows all passwords digests (f(proof) = HUID)
- pro:
- very simple if user remembers password
- cons:
- user-side password storage (post-it, password manager)
- guessable password
- serverside password storage in clear text is dangerous
- pwd sniffing, DB attacks (sql inj), guessing, duplication (many services one password), aging of algorithms, pwd capture via server spoofing and phishing
- MITM attacks
Password best practices
- alphabetic characters (uppercase + lowercase) + digits +special characters
- long (at least 8 characters)
- never use dictionary words
- frequently changed (but not too frequently!)
- don’t use them :-)
- but use of at least one password (or PIN or access code or …) is unavoidable, unless we use biometric techniques
- storing passwords:
- server-side
- never in cleartext
- encrypted password (the server must known the key)
- store digest of the password
- dictionary attack still work
- rainblow table can make dictionary attack faster
- client-side
- should be only in the user’s head
- too many password: use an encrypted file
- server-side
Dictionary attack
When possible: known hash algorithm and password hash values.
Pre-computation: for each word in the dictionary store in the DB hash(word)
Attack: check hash value of unknown password against DB
Pre-computation is key, because creating the DB could take more than the password lifetime.
Rainblow table
Space-time tradeoff technique to store (and lookup) an exhaustive hash table (less space, more time).
Makes exhaustive attack feasible for certain password sets.
Example for 12 digits password:
- exhaustive = 1012 rows
- rainbow = 109 rows, each representing 1000 pwd
- reduction function: r: h => p
- gives a possible password starting from an hash
- pre-computation:
- for(109 distinct P)
- for(p=P, n=0; n<1000; n++)
- k = h(p); p = r(k);
- store(DB, P, p) //chain head and tail
- for(p=P, n=0; n<1000; n++)
- for(109 distinct P)
- attack:
- HP= hash of a passowrd
- for(k = HP; n=0; n < 1000; n++)
- p = r(k)
- if p is key of one of the rows => chain found
- k = h(p)
- exit(“not found”);
- mitigation: using of salts the attacker cannot pre-compute the rainbow table
Rainbow table fusion
The reduction function is going from a hash to one possible password, there could be two different hashes that generates the same password.
Password salting
- Adds a level of randomness to the password to make dictionary pre-computation unfeasible.
- hashed password = hash(pwd || salt)
- verifier strores for each user an hashed password and a salt.
- if someone gets the db they also get the salt, but they will have to calculate the inverse of the passwords from scratch
- two users with the same password will have a different password digest.
passwords in MySQL
the user table contains user passwords that aren’t salted, just double hashed with SHA1.
Strong authN
- Referring to peer authentication.
- often requested in specifications, but never defined precisely
- authn techniques can be regarded as strong or weak depending on the attack model
- internet banking -> ECB def.
- employees of PSP -> PCI-DSS def.
- watch out for application specific risks
ECB strong auth def.
- procedure based on the use of two or more of knowledge, ownership, inherence authn.
- elements selected must be independent (breach of one does not leak the other)
- at least one element should be non-reusable, non-replicable (except for inherence), and impossible to surreptitiously stolen via internet.
- authN procedure should be disgned to protect confidentiality of the authentication data.
PCI-DSS strong authN def.
- v3.2 requires multi-factor auth for access into card-holder data
- from trusted or untrusted network
- by admins
- exception being direct console access (physical sec)
- remote access:
- from untrusted network
- by users and third-parties maintenance
- Multi-factor authn is not 2 times the same factor (two passwords)
CRA
Challenge response authentication
possible way to implement strong authentication.
a challenge is sent to the claimant from the verifier, claimant replies with solution computed using secret knowledge; then the verifier compares expected and actual response.
The challenge must be non-repeateable to avoid replay attacks. (usually the challenge is a random nonce0
Function f must be non-invertible, otherwise listeners can easily discover the shared secret by computing f-1(response, challenge)
Symmetric CRA
- here we have a shared secret between the claimant and verifier, typically a password.
- function f is computed 2 times: from user to make the response, from the verifier to verify match.
- issues:
- easiest implementation: using an hash function
- Kid must be known to verifier
- may lead to attacks against the table containing the passwords
- SCRAM solves this problem by using hashed passwords at the Verifier
- offers also channel binding and mutual authentication
Mutual authentication with symmetric challenge
- v1: only the initiator provides explicitly its (claimed) identity
- v2: less messages
Attack to the symmetric challenge protocol
Here there’s Mike pretending to be Alice. Mike send to Bob the Alice’s identity (A) and Alice’s challenge (𝐶𝐴). Bob
replies with 𝐶𝐵 and 𝑒𝑛𝑐(𝐾𝐴𝐵, 𝐶𝐴 ).
t this point, Mike does not know 𝐾𝐴𝐵 and cannot compute
the response to the challenge. But at this point Mike opens a
new connection with Bob, sending again Alice’s identity (A)
but this time sends the challenge sent from Bob (𝐶𝐵). Bob
replies again with another challenge 𝐶𝐶 and 𝑒𝑛𝑐(𝐾𝐴𝐵 ,𝐶𝐵)
which is the answer to the challenge of the 1st connection.
Mike can finally provide the correct answer.
Asymmetric challenge-response systems
This time the user does not send his identity, but its X.509 certificate, which is declaring his identity and public key (the claimant has the corresponding private key ID.kPri).
R is a random nonce encrypted using claimant public key.
Claimant will then sent the verifier the original value of R if it’s true who they say they are.
Analysis:
strongest mechanism
does not require secret storage at the verifier
implemented for peer authentication in IPsec, SSH, and TLS.
Fundamental for user authentication in FIDO.
Problems:
- slow
- if badly designed could lead to involuntary singature by the Claimant
- PKI issues (trusted root, name constraint, revocation) avoidable if the Verifier stores kPubID
- This is the approach followed by SSH: take public key and public it on the server, with a big risk if someone can change the key stored on the server.
OTP
Users have passwords valid only for one login.
Claimant receives authentication request, that must be replied by using userId; server now requests a specifie password among a list (e.g. no. 48, assuming 49th and 50th have already been used), the user sends the requests password and marks it as used.
The server has the secret used to generate the user’s password, and uses it to verify that the otp was corresponds. This makes password immune to sniffing, ‘cause next time it will be different.
Issues:
- subject to MITM (faking the verifier), verifier authentication is needed to avoid it.
- difficult provisioning: lot of passwords to send to subscribers, password set will be empty at some point.
- untrusted workstaion: use paper sheet or hardware authenticator (crypto token)
- trusted workstation: automatically comput an ad-hoc application
- difficult password insertion: sequence of random characters
The S/KEY system
First OTP definition and implementation by Bell Labs.
- user generate secret Sid
- user computes N one-time passwords where P1 = h(Sid), P2 = h(P1), …
- verifier stores last one (PN), this will be used only indirectly for authentication
- when user wants to access the server, verifier asks for PN-1 and gets X from user. h(X) == PN => ok, store X as PN-1
MITM is possible, so needs server authentication.
Pass generation: users inserts a pass phrase, which must be minimum 8 characters long, if disclosed securty is compromised. Pass phrase is then concatenated with server seed (public), so that the same pp can be used for multiple servers.
Passwords are 64-bit, a compromise, but since they have to be inserted by humans it’s fair enough, otherwise it would take too much time.
OTP problems
uncomfortable: strange passwords.
expensive when based on hardware authenticators
paper based cannot be used by a computer (only by a human)
password provisioning (generator? SMS?)
when time is used to generate OTP, synchronization must be managed (if the attacker makes the user believe it’s 5pm, user will generate code for 5pm)
HW authenticator problems
- denial of service: deliberatly making wrong attempts to block accounts
- social engineering: if authenticator is not physical, it could be possible to call customer support to ask for the initialization of a new authenticator (faking loss of phone)
time based otp
requires local computation
requires clock sync.
requires time-slot and authentication window
only one authenticato run per time-slot
time attacks against subscriber and verifier
sensitive database at the verifier
