15. SSL / TLS
Keine 100% Garantie für sichere Übertragung
Minimum TLS 1.1
Oft nicht korrekt implementiert
https://www.trustworthyinternet.org/ssl-pulse/
16. Basic Authentication
Leicht zu implementieren
In den meisten Libraries vorhanden
Skalierbar
Passwort kann am Server sicher gespeichert werden.
Schnell
(SSL/TLS ein wenig langsamer)
17. Basic Authentication
Passwort im Klartext übertragen
Passwort wird jedes mal übertragen
Passwort muss am Client gespeichert werden
SSL/TLS Pflicht Man in the Middle
Keine Client identifizierung
Auch Third Party Apps benötigen Passwort
Wechsel des Passworts betrifft alle Clients
Keine Signierung der Daten
Replay Attacks
…
27. Digest Access Authentication
opaque
Session Tracking
qop
„auth“, „auth-int“
Bestimmt ob HTTP Body in Digest inkludiert wird
cnonce count
Erhöht sich bei jedem Aufruf
Um Nonce zu erneuern
nonce
Client nonce
Replay Attacks
algorithm
stale
Bei TRUE = nonce ungültig geworden
28. Digest Access Authentication
Passwort wird nicht im Klartext übertragen
Nachrichten Signiert
SSL/TLS nicht Pflicht
Mit nonce/timestamp keine Replay Attacks
29. Digest Access Authentication
Passwort muss am Server als Klartext gespeichert werden
Ohne SSL/TLS Man in the Middle
Passwort muss am Client gespeichert werden
Auch Third Party Apps benötigen Passwort
Wechsel des Passworts betrifft alle Clients
Schlecht Skalierbar
34. Keyed-Hash based message
authentication code (HMAC)
Client
Server
GET http://ex.com/supersave
Authorization: hmac
public_key:timestamp:nonce:digest,
algorithm=”hmac-sha-256”
35. Client
Server
200 OK
checkDigest == digest
checkDigest = hmac("sha256", private_key,
Method + URI + UTC-TS + nonce +
Parameter + Body)
Keyed-Hash based message
authentication code (HMAC)
36. Passwort wird nicht im Klartext übertragen
Nachrichten Signiert
SSL/TLS nicht Pflicht
Mit nonce/timestamp keine Replay Attacks
HMAC sicherer als MD5
Keyed-Hash based message
authentication code (HMAC)
37. Passwort muss am Server als Klartext gespeichert werden
Ohne SSL/TLS Man in the Middle
Passwort muss am Client gespeichert werden
Auch Third Party Apps benötigen Passwort
Wechseln der Passwört betrifft alle Clients
Keyed-Hash based message
authentication code (HMAC)
42. OAuth User Sicht
Hello stkienzl,
This is a statistic about your
tweets:
.....
http://www.sync.com.my/version2.0/twitter_signup/index.php http://dinochiesa.net/?p=17
43. OAuth Developer Sicht
Zugang zu Daten über Access Token
Access Token in allen Versionen unterschiedlich
Wie kommt man einen Access Token?
46. OAuth 1.0 Access Token
Können zeitlich unbegrenzt gültig sein
Hat ein Token Secret dabei (“Private Key”) für Signatur
Muss vom Resource Owner wieder entzogen werden
57. OAuth 1.0a Signature
Signature Base String = Method +“&“+ URL +“&“+ parameter
Method (zB GET, POST ....)
URL
Ohne default Port (80 oder 443)
Ohne GET Parameter
Alles klein
HTTP Authorization Headers (außer realm), POST bzw GET Parameter
Nach Key, Value aufsteigend sortiert
Signature Key = Cosumer_Secret +“&“+ Token_Secret
HMAC-SHA1(Signature Base String , Signature Key)
59. Passwort muss nicht am Client gespeichert werden
Third Party Apps brauchen Passwort nie
Nachrichten Signiert
SSL/TLS nicht Pflicht
Mit nonce/timestamp keine Replay Attacks
Mit HMAC gesichert
Passwort wechsel keine Auswirkung auf Clients
OAuth 1.0a
60. Client Credentials als Klartext gespeichert am Server/Client
Keine Authentifizierung (Native Apps)
Keine Unterstützung für Client Based App (JavaScript Apps)
Bedingt Skalierbar
Kompliziert
OAuth 1.0a
61. OAuth 1.0a OAuth 2
Zu Kompliziert
Schwer zu starten wegen Signatur
Kein Support für native Apps
Kein Support für Client-Based Apps
Schlecht Skalierbar
API (Resource Server) braucht auch alle Secrets
90. Passwort muss nicht am Client gespeichert werden
Third Party Apps brauchen Passwort nie
Auch Authentifizierung
Unterstütz auch Client Based Apps
Gut Skalierbar
OAUTH 2+ MAC Nachrichten auch signiert
Token nur begrenzt gültig
Mit Refresh Token leicht neuen anfordern
Passwort wechsel keinAauswirkung auf Clients
Weit verbreitet
OAuth 2
91. SSL/TLS Pflicht
Bei Authentifizierung muss Passwort im Klartext übertragen werden
Client Credentials als Klartext gespeichert am Server/Client
Kompliziert wenn man alle Implementierung verstehen will
Unsicherer als OAuth 1.0a
OAuth 2