Test
10c Authentification protocols
Este test tiene tipos de pregunta que se abren en el reproductor de siempre.
Preguntas del test (24)
1What is [blank_start]challenge[blank_end]-[blank_start]response[blank_end]?
Rather than sending the [blank_start]password[blank_end] to the server,
> Server sends client a [blank_start]challenge[blank_end]
> Clients uses the password [blank_start]hash[blank_end] to create a response (HMAC o the challenge)
:( Still vulnerable to [blank_start]MITM[blank_end] attacks
Sol: Signs the packets with a key derived from the pwd [blank_start]hash[blank_end] > attacker can't know the key, cannot send the packets!
- Achallenge
- Bresponse
- Cpassword
- Dchallenge
- Ehash
- FMITM
- Ghash
2The challenge-response can be used for a [blank_start]mutual[blank_end] authentification, so the client can also authenticate the server.
:( vulnerable to [blank_start]eavesdropping[blank_end] and [blank_start]cracking[blank_end] attacks
> Attacker [blank_start]records[blank_end] a challenge and a response then tries all possible password to yield the same response.- Aeavesdropping
- Bcracking
- Crecords
- Dmutual
3[blank_start]OAuth2[blank_end] is a tool for [blank_start]delegated[blank_end] authentification on the Internet.
Ex. you log in to Pinterest with Facebook or Google.- Adelegated
- BOAuth2
4The roles in delegated authentifications are like this:
- [blank_start]Client[blank_end]: application that want to use authentification and to access user [blank_start]data[blank_end] (Pinterest wants user's photo)
- [blank_start]Resource[blank_end] server: server that [blank_start]has[blank_end] user's data (Facebook server having users' photos)
- [blank_start]Authorization[blank_end] server: server on which the user [blank_start]authenticates[blank_end] (Facebook authentification server)
-[blank_start]User[blank_end]: [blank_start]owner[blank_end] of the account and the resources.- AClient
- Bdata
- CResource
- Dhas
- EAuthorization
- Fauthenticates
- GUser
- Howner
5Oauth2 flow:
The client and the [blank_start]authentification[blank_end] server share a [blank_start]secret[blank_end].
> The client has to register with the authentification server before authenticating.
> The [blank_start]secret[blank_end] is used when the client exchanges the [blank_start]authentification[blank_end] [blank_start]code[blank_end] for an [blank_start]access[blank_end] [blank_start]token[blank_end].
> The [blank_start]authentification[blank_end] code is not sufficient to get access to the resources.
The client app can:
1) Open a [blank_start]webview[blank_end] within the app (not secure)
2) Switch to the other app
- Aauthentication
- Bsecret
- Csecret
- Dauthentication
- Ecode
- Faccess
- Gtoken
- Hauthentication
- Iwebview
6The oath2 is only used for loggin. The client app do not [blank_start]store[blank_end] your password. So when you change your password, you do not need to type your new password to all your devices.
- Astore
7The oath2 to delegate authentification has no [blank_start]cryptography[blank_end] at all and relies on [blank_start]TLS[blank_end].
- Acryptography
- BTLS
8Name a second authentification factor that can also be used to sign transaction?
- ATAN calculator
- BSmartphone
- CBingo cards
- DOne-time password tokens
- EPrivate key on a hardware token
9What is the big advantage of using U2F versus OTP?
[blank_start]Client[blank_end] and [blank_start]Server[blank_end] can both be [blank_start]attacked[blank_end].- AClient
- BServer
- Cattacked
10Biometric authentification system with FAR of 0.01% is a good system.
- AVerdadero
- BFalso
11Kerberos provides [blank_start]authentication[blank_end] and [blank_start]authorization[blank_end] across a network.
- Aauthentication
- Bauthorization
12Kerberos uses a three step approach:
1-2) An [blank_start]authentication[blank_end] [blank_start]server[blank_end] (AS) authenticates the client and [blank_start]delivers[blank_end] a [blank_start]ticket[blank_end] [blank_start]granting[blank_end] [blank_start]ticket[blank_end] (TGS)
3-4) The client can present the TGT to the [blank_start]ticket[blank_end] [blank_start]granting[blank_end] [blank_start]server[blank_end] (TGS) to get a [blank_start]ticket[blank_end] for the services he wants to use
5-6) [blank_start]Access[blank_end] to the service
- Aauthentication
- Bserver
- Cdelivers
- Dticket
- Egranting
- Fticket
- Gticket
- Hgranting
- Iserver
- Jticket
- KAccess
13Kerberos authentication:
1. Client that asks for a ticket for the TGS sends ([blank_start]c[blank_end], [blank_start]tgs[blank_end])
2. The [blank_start]authentication[blank_end] server responses with the [blank_start]ticket[blank_end] [blank_start]granting[blank_end] [blank_start]ticket[blank_end] T_c,tgs and an [blank_start]encrypted[blank_end] [blank_start]session[blank_end] [blank_start]key[blank_end] ENC_Kc (K_c, tgs)
- Ac
- Btgs
- Cticket
- Dgranting
- Eticket
- Fauthentication
- Gencrypted
- Hsession
- Ikey
14Kerberos authorization:
2.4) The client decrypts the [blank_start]encrypted[blank_end] [blank_start]session[blank_end] [blank_start]key[blank_end] ENC_Kc (K_c, tgs) with [blank_start]K_c[blank_end] => client's [blank_start]password[blank_end] hash.
2.5) The client creates an [blank_start]authenticator[blank_end] with the session key K_c, tgs =>
Authenticator = [blank_start]id[blank_end] + [blank_start]timestamp[blank_end] encrypted with a [blank_start]session[blank_end] [blank_start]key[blank_end]
A_c, tgs = ENC_K_c, tgs {c, t}
3) The client sens the [blank_start]ticket[blank_end] [blank_start]granting[blank_end] [blank_start]ticket[blank_end] T_c, tgs and the [blank_start]authenticator[blank_end] A_c, tgs to the [blank_start]ticket[blank_end] [blank_start]granting[blank_end] [blank_start]server[blank_end] (TGS)
4) The TGS verifies the [blank_start]authenticator[blank_end] (by decrypting the [blank_start]authenticator[blank_end] with the [blank_start]session[blank_end] [blank_start]key[blank_end] of the client to see if he gets the c ([blank_start]id[blank_end]) and a [blank_start]newer[blank_end] [blank_start]timestamp[blank_end] of the client)
5) The TGS grants the client with a [blank_start]service[blank_end] [blank_start]ticket[blank_end] T_c, s and an encrypted [blank_start]session[blank_end] [blank_start]key[blank_end] ENC_c, tgs (K_c, s)
- Aencrypted
- Bsession
- Ckey
- DK_c
- Epassword
- Fauthenticator
- Gid
- Htimestamp
- Isession
- Jkey
- Kticket
- Lgranting
- Mticket
- Nauthenticator
- Oticket
- Pgranting
- Qserver
- Rauthenticator
- Sauthenticator
- Tsession
- Ukey
- Vid
- Wnewer
- Xtimestamp
- Yservice
- Zticket
- AAsession
- ABkey
15Kerberos access:
4.4) The client [blank_start]decrypts[blank_end] the encrypted session key given by the [blank_start]ticket[blank_end] [blank_start]granting[blank_end] [blank_start]server[blank_end] with the [blank_start]session[blank_end] [blank_start]key[blank_end] given by the [blank_start]authentication[blank_end] server.
4.5) The client creates an [blank_start]authenticator[blank_end] with the session key K_[blank_start]c[blank_end],[blank_start]s[blank_end] given by the ticket granting server =>
Authentication = [blank_start]id[blank_end] + [blank_start]timestamp[blank_end] [blank_start]encrypted[blank_end] with [blank_start]session[blank_end] [blank_start]key[blank_end] K_c,s
A_c, s = ENC_K_c, s (c, ts)
5) The client sends the [blank_start]authenticator[blank_end] and the [blank_start]service[blank_end] [blank_start]ticket[blank_end] T_c, s to the server
6) The server verifies the authenticator by decrypting it with the [blank_start]session[blank_end] [blank_start]key[blank_end] K_[blank_start]c[blank_end], [blank_start]s[blank_end] to see if there is the client [blank_start]id[blank_end] (c) and a [blank_start]new[blank_end] timestamp
7) The client can now use the service
- Adecrypts
- Bticket
- Cgranting
- Dserver
- Esession
- Fkey
- Gauthentication
- Hauthenticator
- Ic
- Js
- Kid
- Ltimestamp
- Mencrypted
- Nsession
- Okey
- Pauthenticator
- Qservice
- Rticket
- Ssession
- Tkey
- Uc
- Vs
- Wid
- Xnew
16In Kerberos, there are 3 servers:
a) [blank_start]Authenticating[blank_end] server
b) [blank_start]Ticket[blank_end] [blank_start]granting[blank_end] server
c) [blank_start]Service[blank_end] server- AAuthenticating
- BTicket
- Cgranting
- DService
17In Kerberos, the ticket obtained from the authentication server is called the ticket granting ticket because it is [blank_start]used[blank_end] to [blank_start]get[blank_end] other [blank_start]tickets[blank_end].
- Aused
- Bget
- Ctickets
18In Kerberos, for any server, we always have to send the Ticket granting ticket.
- AVerdadero
- BFalso
19A ticket is encrypted with the key of the [blank_start]destination[blank_end] server:
T_c, s = ENC_K_s {c, a, v, K_c, s}
where
c = [blank_start]client[blank_end] [blank_start]id[blank_end]
a = client [blank_start]IP[blank_end] [blank_start]address[blank_end]
v = [blank_start]validity[blank_end] period
K_c,s = [blank_start]session[blank_end] [blank_start]key[blank_end] used between client / server
In Kerberos, for a server to validate a ticket, the server:
- [blank_start]decrypts[blank_end] the ticket
- validates the [blank_start]IP[blank_end] address and the [blank_start]validity[blank_end] period (v)
- use the included [blank_start]session[blank_end] [blank_start]key[blank_end] to
>> decrypt the [blank_start]authenticator[blank_end]
>> verify that it contains the same [blank_start]id[blank_end] c as the [blank_start]ticket[blank_end]
- verifies the [blank_start]authenticator[blank_end] is fresh (ts in less thant 5 min)
- verifies the same [blank_start]authenticator[blank_end] has not been used for the last 5 min
Tickets are typically valid for 8 hours.- Aclient
- Bid
- CIP
- Daddress
- Evalidity
- Fsession
- Gkey
- Hdestination
- Idecrypts
- JIP
- Kvalidity
- Lsession
- Mkey
- Nauthenticator
- Oid
- Pticket
- Qauthenticator
- Rauthenticator
20The MITM attacks is not possible in Kerberos, because the attacker doesn't know the session keys (K_[blank_start]c[blank_end], K[blank_start]c[blank_end]_[blank_start]tgs[blank_end], K[blank_start]c[blank_end]_[blank_start]s[blank_end]) .
The attcker doesn't know the keys K_[blank_start]tgs[blank_end], K_[blank_start]s[blank_end] used to encrypt the [blank_start]tickets[blank_end].
The attacker cannot modify any [blank_start]ticket[blank_end] / authenticator.- Ac
- Bc
- Ctgs
- Dc
- Es
- Ftgs
- Gs
- Htickets
- Iticket
21Replay attack is not possible in Kerberos, because:
- Attacker cannot [blank_start]reuse[blank_end] an old authenticator, only fresh ones are accepted
- Attacker cannot [blank_start]replay[blank_end] fresh authenticator, the server keep a list of the authenticator received.- Areplay
- Breuse
22Since anyone can request a ticket for a used c ([blank_start]id[blank_end]) from the [blank_start]authentication[blank_end] service in Kerberos, a possible attack would be to [blank_start]brute[blank_end] [blank_start]force[blank_end] the password by trying to decrypt the [blank_start]session[blank_end] [blank_start]key[blank_end] [blank_start]K[blank_end]_c, [blank_start]tgs[blank_end] with password [blank_start]hashes[blank_end].
- Asession
- Bkey
- Cbrute
- Dforce
- Eid
- Fauthentication
- Ghashes
- HK
- Itgs
23In Kerberos, [blank_start]Pre[blank_end]-[blank_start]authentication[blank_end] is used to prevent brute-forcing the session key given by the authentication server.
> The user must send an [blank_start]authenticator[blank_end] to request a [blank_start]ticket[blank_end] [blank_start]granting[blank_end] ticket.
> The K_c to encrypt the session key is not the [blank_start]password[blank_end] [blank_start]hash[blank_end] anymore, but it's derived from the password hashing using salt and SHA1.
1) The client creates an [blank_start]authenticator[blank_end] with K_c (pwd hash, salt, iteration)
2) THe client asks for a [blank_start]ticket[blank_end] [blank_start]granting[blank_end] [blank_start]ticket[blank_end] by sending [blank_start]c[blank_end], [blank_start]tgs[blank_end], [blank_start]authenticator[blank_end] A_c
where A_c = ENC_K_c (c, ts)
3) The authentication server respons with ticket T_c, tgs and an encrypted session key ENC_K_c (K_c, tgs) if A_c is valid
- APre
- Bauthentication
- Cauthenticator
- Dticket
- Egranting
- Fpassword
- Ghash
- Hauthenticator
- Igranting
- Jticket
- Kticket
- Lc
- Mtgs
- Nauthenticator
24The security of Kerberos relies on [blank_start]symmetric[blank_end] keys.
- Between client and AS: the [blank_start]password hash[blank_end]
- Between AS and TGS : [blank_start]K_tgs[blank_end]
- Between TGS and service server: [blank_start]K_s[blank_end]
- Asymmetric
- Basymmetric
- Cpassword hash
- DK_tgs
- EK_s
- FK_c, tgs
- GK_tgs
- HK_c
- IK_s
- JK_c, tgs
- KK_s
- LK_c
- MK_c, tgs
- NK_c, s
Información
- Descripción
- - (10 Access control, Authentication & protocols) Information security Test sobre 10c Authentification protocols, creado por Yawen Hou el 04/06/2019.
- Autor
- Yawen Hou
- Idioma
- English
- Visitas
- 0
- Etiquetas
- Valoración
- Aún sin valoraciones Valora este test