{"id":290,"date":"2018-06-01T04:43:39","date_gmt":"2018-06-01T04:43:39","guid":{"rendered":"https:\/\/www.wpvs.de\/iot-2018\/?p=290"},"modified":"2021-05-14T10:07:05","modified_gmt":"2021-05-14T08:07:05","slug":"smartlock-4-sicherheit-geht-vor","status":"publish","type":"post","link":"https:\/\/www.iot-embedded.de\/iot-2018\/projekt-smart-lock\/smartlock-4-sicherheit-geht-vor\/","title":{"rendered":"SmartLock (4): Sicherheit geht vor"},"content":{"rendered":"

Nachdem ihr im vorherigen Blogbeitrag \u00fcber die API hinter dem Projekt \u201eSmart Lock\u201c geh\u00f6rt habt, wollen wir in diesem Beitrag das Sicherheitskonzept von \u201eSmart Lock\u201c erl\u00e4utern. Gerade bei einer intelligenten T\u00fcrsteuerung ist es wichtig, dass alle g\u00e4ngigen Sicherheitsfeatures eingehalten werden. Dieser Prozess beginnt bei uns bereits auf der Hardwareseite und erstreckt sich \u00fcber alle Aspekte des Endger\u00e4ts.<\/p>\n

1. Sicheres Hashing aller Passw\u00f6rter<\/h3>\n

Innerhalb der Benutzeroberfl\u00e4che k\u00f6nnen sich Administratoren einloggen und ihre Zugangsdaten verwalten. Wurde ein Passwort ge\u00e4ndert, sendet die Benutzeroberfl\u00e4che eine Anfrage an die\u00a0Web-API der Anwendung. Hier wird das Passwort mit dem bcrypt-Verfahren gehasht und anschlie\u00dfend in der Datenbank gespeichert.<\/p>\n

Wir verwenden bcrypt, da es von Sicherheitsforschern empfohlen wird. Betrachtet man die Historie der Hashing-Verfahren erkennt man, dass die empfohlenen Verfahren h\u00e4ufig wechseln. Dies ist auf die stetig steigende Rechenkapazit\u00e4t der Endger\u00e4te zur\u00fcckzuf\u00fchren (Moore\u2019s Law). \u00c4ltere Verfahren wie etwa MD5 oder SHA1 (bzw. SHA256 oder SHA512) sind demnach \u00fcberholt. Der zugrundeliegende Algorithmus dieser Verfahren kann immer schneller ausgef\u00fchrt werden, wodurch Brute-Force-Angriffe einfacher m\u00f6glich sind. Hingegen verfolgt Bcrypt das Ziel deutlich rechenintensiver als zuvor bekannte Hashing-Verfahren zu sein. Die Berechnung eines Hashs wird somit erschwert, was aber bei einer normalen Nutzung des Algorithmus nicht ins Gewicht f\u00e4llt. Gleichzeitig werden Brute-Force-Angriffe stark verlangsamt.<\/p>\n

\"\"
Schema eines brypt Hashes Quelle: CC BY-SA 3.0 Andrei Herford<\/a><\/figcaption><\/figure>\n

Au\u00dferdem ist das sogenannte \u201esalting\u201c der Passw\u00f6rter zu beachten. Jedem Nutzer wird hierbei ein zufallsgenerierter Token zugewiesen. Dieser wird bei jedem Login an das Passwort angeh\u00e4ngt wird. Aus dem Passwort \u201e1234\u201c w\u00fcrde dadurch zum Beispiel das Passwort \u201e1234d3RM*qA@9W\u201c werden. Anschlie\u00dfend wird das neue Passwort gehasht und wie ein normales Passwort behandelt. Dieses Verfahren wird haupts\u00e4chlich angewendet, um die Nutzung sogenannter Rainbow Tables zu unterbinden. Eine Rainbow Table \u00e4hnelt einem W\u00f6rterbuch. Jedem Hash wird sein urspr\u00fcnglicher Wert zugeordnet, wodurch ein Angreifer das eigentliche Passwort bestimmen kann.<\/p>\n

 <\/p>\n

\"\"
Laut Moore’s Law verdoppelt sich die Rechenkapazit\u00e4t alle 12 bis 24 Monate
Quelle: CC BY-SA 3.0 Wgsimon<\/a><\/figcaption><\/figure>\n

2. Eindeutige Identifikation der Nutzer durch Sessions<\/h3>\n

Wie ihr schon im vorherigen Post gesehen habt, stellt die API eine Methode bereit, mit der sich Nutzer in der Anwendung anmelden k\u00f6nnen. Innerhalb dieser Funktion wird das eingegebene Passwort gehasht. Im Anschluss wird der generierte Hash-Wert mit dem hinterlegten Hash-Wert der Datenbank verglichen. Stimmen beide \u00fcberein, wird der Zugriff auf die Anwendung gew\u00e4hrt und eine verschl\u00fcsselte serverseitige Session erstellt. Diese enth\u00e4lt dann alle Informationen des angemeldeten Admins. Anhand dieser Session kann in jedem weiteren API-Aufruf die Identit\u00e4t des Nutzers gew\u00e4hrleistet werden und eine unerlaubte Nutzung der API verhindert werden. Weiterhin kann die serverseitige Session nicht durch den Admin manipuliert werden, was bei einer clientseitigen Sessions durchaus m\u00f6glich w\u00e4re.<\/p>\n

W\u00e4hlt der Nutzer den Logout in der Weboberfl\u00e4che aus, wird seine Session im Backend zerst\u00f6rt. Nach einer l\u00e4ngeren Inaktivit\u00e4t l\u00e4uft die Session aus und der Nutzer wird automatisch ausgeloggt.<\/p>\n

\"\"
Die Sessions werden durch eine methoden\u00fcbergreifende Middleware verwaltet.<\/figcaption><\/figure>\n

3. Verifikation aller API-Anfragen<\/h3>\n

Die Middleware wird weiterhin verwendet, um alle API-Endpoints abzusichern. Die Middleware pr\u00fcft bei jedem einzelnen Aufruf, ob eine valide Session besteht. Ist dies nicht der Fall, wird der Statuscode HTTP 401 zur\u00fcckgegeben. Durch diesen Mechanismus k\u00f6nnen wir sicherstellen, dass die API nicht missbraucht wird.<\/p>\n

4. Korrekte Berechtigungstrennung unter Linux<\/h3>\n

Die korrekte Trennung der Berechtigungen unter Linux ist wichtiger als alle bisher erl\u00e4uterten Sicherheitsma\u00dfnahmen. Diese besagt, dass Node.js niemals mit Root-Rechten ausgef\u00fchrt werden darf. So kann sichergestellt werden, dass eventuelle Fehler in der API nicht zum Erlangen von Superuser-Rechten missbraucht werden. Idealerweise wird die fertige Anwendung niemals Root-Rechte anfordern m\u00fcssen, um nicht die Integrit\u00e4t der Firmware zu gef\u00e4hrden. Denn mit Superuser-Rechten k\u00f6nnen alle Bestandteile der Firmware eingesehen und ge\u00e4ndert werden.<\/p>\n

Ich hoffe, dass ihr ein paar interessante Einblicke in unser Sicherheitskonzept erlangen konntet. Wei\u00dft uns gerne in den Kommentaren auf eventuelle Unstimmigkeiten hin :).<\/p>\n","protected":false},"excerpt":{"rendered":"

Nachdem ihr im vorherigen Blogbeitrag \u00fcber die API hinter dem Projekt \u201eSmart Lock\u201c geh\u00f6rt habt, wollen wir in diesem Beitrag das Sicherheitskonzept von \u201eSmart Lock\u201c erl\u00e4utern. Gerade bei einer intelligenten T\u00fcrsteuerung ist es wichtig, dass alle g\u00e4ngigen Sicherheitsfeatures eingehalten werden.<\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[5],"tags":[],"_links":{"self":[{"href":"https:\/\/www.iot-embedded.de\/iot-2018\/wp-json\/wp\/v2\/posts\/290"}],"collection":[{"href":"https:\/\/www.iot-embedded.de\/iot-2018\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.iot-embedded.de\/iot-2018\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.iot-embedded.de\/iot-2018\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/www.iot-embedded.de\/iot-2018\/wp-json\/wp\/v2\/comments?post=290"}],"version-history":[{"count":1,"href":"https:\/\/www.iot-embedded.de\/iot-2018\/wp-json\/wp\/v2\/posts\/290\/revisions"}],"predecessor-version":[{"id":656,"href":"https:\/\/www.iot-embedded.de\/iot-2018\/wp-json\/wp\/v2\/posts\/290\/revisions\/656"}],"wp:attachment":[{"href":"https:\/\/www.iot-embedded.de\/iot-2018\/wp-json\/wp\/v2\/media?parent=290"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.iot-embedded.de\/iot-2018\/wp-json\/wp\/v2\/categories?post=290"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.iot-embedded.de\/iot-2018\/wp-json\/wp\/v2\/tags?post=290"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}