Skip to content

Authentifizierung & Authorisierung

Jump to bottom Edit New page
Jörg Reichardt edited this page Apr 16, 2014 · 8 revisions

Einführung

Da wir eine große Menge sensibler Daten verwalten ist Sicherheit eines unserer wichtigsten Entwurfsziele.

Authentifizierung (Sicherstellen, wer der Benutzer ist) und Authorisierung (Sicherstellen, was der Benutzer darf) sind dabei zwei Kernaspekte.

Authentifizierung

Die Authentifizierung gewährleisten wir mittels Devise.

OWASP empfiehlt folgende Architekturziele für sichere Authentifizierung_(kursiv wird angemerkt, wie wir diese Anforderungen umsetzen)_:

Architectural Goals

All applications should take into account the following architectural and detailed design goals:

  • All applications within your organization SHOULD share a well-debugged and trusted authentication mechanism if possible (Devise ist gut getestet gilt als Vertrauenswürdig)

  • All secured functions and secured resources SHOULD be protected by a common authentication mechanism within the one application (:authorize_resource wird in allen geschützten Controllern aufgerufen)

  • All applications MUST use the lowest possible privilege service account to access back end systems such as directories, web services, database and message queues

  • Credentials SHOULD be transmitted only over encrypted links, particularly weak authentication mechanisms such as passwords (Alle links laufen über das https-Protokoll)

  • Credentials MUST be stored after being one-way hashed and salted using acceptable hashing algorithms (Es wird bcrypt verwendet)

  • Credential stores SHOULD implement configurable settings for thresholds, lockouts, password complexity and alerts TODO

  • Credential stores SHOULD be designed to implement several hashing algorithms as these will be replaced soon and as change is inevitable, your application should plan today for this transition

  • Applications SHOULD have the facility to alert the user as to failed login attempts and offer to allow them to change their password (if applicable)

  • Applications SHOULD have the facility to notify the user of their last logged in time, and subsequently report a fraudulent login if they disagree with that date and time

  • Authentication and registration processes, particularly login failures, SHOULD provide no information as to if an account exists or password or is wrong. A single error message for the end user covering both scenarios is more than adequate TODO

  • All pages SHOULD have an effective logout button on every single page in a common location (Wird in der 'roten Leiste' überall angeboten)

  • Applications SHOULD possess administrative functions to detail and manage never logged in accounts, idle accounts, and accounts that have been administratively- or soft- locked

  • Passwords MUST be easily changed. Applications MAY include password strength indicators or provide a random password generator function (Administratoren können mit einem einfachen klick neue zufällige Passwörter generieren) TODO: Eigene Passwörter wählen, mit einer Hürde für Passwortstärke

  • There SHOULD be a logical difference between administrative lockout and failed login lockout, so that re-enabling all users en masse does not unlock administratively locked users

  • Medium value applications SHOULD and High value applications MUST provide a mechanism to re-authenticate or transaction sign high value transactions (Wir gelten als "low value" Anwendung)

  • Applications MUST protect credentials from common authentication attacks as detailed in the Testing Guide. Following the sections in this chapter will produce such an outcome

Things not to do:

  • Applications MUST NOT store any secret part of the credential in the clear (passwords or questions and answers if implemented) (Wir verwenden bcrypt und verzichten auf "Sicherheits"-fragen)
  • Applications MUST NOT expose the credential in untrusted locations, such as cookies, headers or hidden fields
  • Applications MUST NOT implement CAPTCHA as there is case law against them with respect to universal access and ineffective (Wir verwenden keine CAPTCHAs)
  • Applications MUST NOT implement questions and answers as they are contrary to most privacy regimes and ineffective (Wir verwenden keine "Sicherheits"-fragen)
  • Applications SHOULD NOT rely on infrastructure authentication, such as REFERER headers or the client's DNS or IP address as these can be faked (Wir nutzen keine REFERER headers oder IP-Adressen für die Authentifizierung)

Password Guidelines

Passwords are intrinsically weak. Therefore, your application should encourage good password practices:

  • Credentials should only traverse encrypted links (wird immer über https gesendet)
  • Store the password in a strongly hashed and salted format to prevent rainbow table attacks. (Wir verwenden bcrypt)
  • Pass phrases (long passwords over 20 characters in length) should be encouraged
  • Short passwords should be prohibited
  • Do not force folks to change passwords frequently as this results in the users writing the passwords down insecurely (Wird nicht erzwungen)
  • Where suitable, try to share the credential with as many low value systems as possible to encourage one single high quality password TODO: OAUTH erlauben
  • Allow expert users to store strong passwords in approved password managers. Encourage them to use unique random passwords for each service

Remember Me

Implementing remember me functionality can be incredibly hard. Often software will just embed the username and password in headers or cookies, or a hash or crypto blob of the same. Based upon your risk profile, your application:

  • High value applications MUST NOT possess remember me functionality. [...]
  • Low value applications MAY include an opt-in remember me function. There should be a warning to the user that this option is insecure, particularly on public computers. Im Moment ist Remember Me immer und für immer an. Es gibt einen Hinweis.

Authorisierung

Die Authorisierung gewährleisten wir mittels CanCan

Alle Rechte sind zentral in der Ability-Klasse definiert.

Wir haben folgende Konvention: :manage-Rechte haben nur (lokale oder globale) Administratoren. Wenn ein Benutzer trotzdem alles darf (z.B. sein eigenes Profil bearbeiten), dann müssen ihm alle Rechte einzeln gewährt werden. Der einfachheit halber gibt es aber für die vier Standard-Rechte create, read, update, delete ein alias :crud.

Add a custom footer
Add a custom sidebar
Clone this wiki locally