Rest Service Authentifizierung und Sicherheit Konzept

[fillibuster]

Hallo,

derzeit entwickle ich eine Anwendung, die mit einem REST Webservice kommunizieren soll. Die Frage, wie sichere ich das ganze vernünftig ab? Bisher ist mein Vorgehen wie folgt (grob gezeichnet):

• SERVER-Benutzer meldet sich am Server mit Benutzername und Passwort an (einmalig über Webinterface)
• SERVER-Passwort wird als gesalzener Hash in DB geschrieben
• SERVER-Aus Teilen von diesem Hash wird ein gesalzener Authentifizierungsschlüssel generiert
• CLIENT-Benutzer gibt Benutzername und Passwort ein - Passwort wird verschlüsselt gespeichert
• CLIENT-Jetzt kommt die eigentliche Anfrage an den Webservice: Passwort wird auf dem Client entschlüsselt, gehasht und der gesalzene Authentifizierungsschlüssel generiert und pro Request gesendet
• Kommunikation läuft über SSL

Die Anwendung soll kommerziell werden. Ich denke, das Thema Sicherheit habe ich schon ganz gut mit der obigen Vorgehensweise im Griff, aber was mir Bauchschmerzen bereitet: Was mache ich, wenn ein böser Bube einen CLienten knackt. So erhält er alle Infos zu den Verschlüsselungen und könnte den kompletten Server kompromittieren. Was mein Ihr?

Viele Grüße...

[jfheins]

Mir ist nicht ganz klar warum du das Passwort auf dem Cient verschlüsselt (statt gehasht) speicherst.
Überhaupt könntest du darauf verzichten:

Nachdem sich der Benutzer auf dem Server angemeldet hat, generierst du einen komplett zufälligen Zugriffsschlüssel. (oder wie du es nennen möchtest)
Ein Zugriffsschlüssel ist genau einem Benutzer und einer Anwendung zugeordnet. Der Benutzer kopiert diesen jetzt in den Client.
Der Client meldet sich mit Username, Passwort-Hash (?) und Zugriffsschlüssel an und bekommt damit (falls alles gültig ist) Zugriff.

So (oder so ähnlich) läuft das ja auch bei Twitter oder Facebook, vll. kannst du dir das Prinzip abgucken ;-)

[fillibuster]

Hi,

danke für deine Antwort!

Zitat:

Zitat von jfheins (Beitrag 1176268)

Mir ist nicht ganz klar warum du das Passwort auf dem Cient verschlüsselt (statt gehasht) speicherst.

Damit der Hash nicht im "Klartext" irgenwo in den Einstellungen steht (daraus wird ja mein Zugriffsschlüssel generiert).
Die von dir skizzierte Vorgehensweise klingt logisch! Allerdings ist mir nicht klar, wieso der Bentutzer sich mit Username, Passwort und Zugriffsschlüssel anmelden soll. Nur Zugriffsschlüssel würd ja eigentlich reichen, oder?

Viele Grüße ...

[jfheins]

Ja, schon. Das wird dann wohl OAuth sein. ( http://de.wikipedia.org/wiki/Oauth )

Zumindest bei Twitter braucht man keinen Passwort Hash (der Client bekommt also zu keinem Zeitpunkt dass Passwort zu sehen) aber da ist noch einiges an Hashing und so dabei. ( https://dev.twitter.com/docs/auth/authorizing-request )

Die Sache mit "Kein Passwort beim Client" ist dann auch schon das Sicherheitsfeature. Den Zugriffsschlüssel sollte man natürlich im online Account sperren können.

[BUG]

Zitat:

Zitat von fillibuster (Beitrag 1176267)

• SERVER-Passwort wird als gesalzener Hash in DB geschrieben

Hier gibt es eine interessanten Überblick zu Hashing von Passwörtern.
tl;dr: Normales Hashing geht zu schnell um sicher zu sein, nutze daher: bcrypt oder PBKDF2.



Wenn du eh SSL nutzt, könntest du auch "einfach" Zertifikate zur Authentifizierung von Client und Server nehmen.

Das Problem das ein Client potenziell immer feindlich ist, wirst du nicht überwinden können.
Wenn es sinnvoll/nötig ist, könntest du serverseitig ein Rechtesystem verwalten um den Schaden gering zu halten.

[fillibuster]

Hi,
@jfheins: ich glaube in diese Richtung wird die Reise gehen. Diesen API-Key könnte man ja dann zusätzlich auf dem Clienten verschlüsselt speichern (je nach Implementierung (Delphi, Android ...) unterschiedlich).

Zitat:

Zitat von BUG (Beitrag 1176273)

...
Wenn es sinnvoll/nötig ist, könntest du serverseitig ein Rechtesystem verwalten um den Schaden gering zu halten.

Der Schaden bestände dann ja höchstens aus einem geklautem APIKey, welchen man dann sperren kann, oder ging deine o. g. Aussage in eine andere Richtung?

Vielen Dank und viele Grüße ...

[BUG]

Zitat:

Zitat von fillibuster (Beitrag 1176283)

Der Schaden bestände dann ja höchstens aus einem geklautem APIKey, welchen man dann sperren kann, oder ging deine o. g. Aussage in eine andere Richtung?

Ich meinte:
Der Schaden den man mit einem geklauten API-Key anstellen kann, ist genauso groß, wie der zum Key gehörige Nutzer auf dem Server Rechte dazu hat. Wenn nicht eh jeder Benutzer alles machen kann, sollte die Überprüfung, ob der Nutzer etwas darf, (auch) auf dem Server stattfinden.

Eigentlich ist es klar, aber im Eifer des Gefechts neigt man ja dazu, sowas zu vergessen :mrgreen:

[fillibuster]

Hi,

Zitat:

Zitat von BUG (Beitrag 1176285)

Der Schaden den man mit einem geklauten API-Key anstellen kann, ist genauso groß, wie der zum Key gehörige Nutzer auf dem Server Rechte dazu hat. Wenn nicht eh jeder Benutzer alles machen kann, sollte die Überprüfung, ob der Nutzer etwas darf, (auch) auf dem Server stattfinden.

Ah ok, das ist sowiso gesetzt.

Danke für eure Antworten!

[mquadrat]

Zitat:

Normales Hashing geht zu schnell um sicher zu sein

?? Ich bin mir nicht sicher, ob mein Krypo-Prof, das in der Uni als Antwort hätte durchgehen lassen :-D


Zum Thema: OAuth? Benutzen (fast) alle anderen ja auch.