Seite 2 von 2 ErsteErste 12
Ergebnis 21 bis 33 von 33
  1. #21
    Mitglied

    (Threadstarter)


    Registriert seit
    Oct 2004
    Beiträge
    2.369
    Danksagungen
    19

    Standard Re: Gulli:Board gehackt -- aus dem Feedback

    Also willst Du doch nur
    Salt + PW+ Pepper
    oder
    Pepper + PW + Salt
    machen?
    War Dein Pattern nicht eher
    "PA(Pepper)SSW(Salt)ORT"
    Wenn dem so ist, musst Du den PW-String ja erstmal zerlegen. Also entweder in einzelne Chars (str_split) oder Substrings (substr).
    Also schon die erste Stringfunktion notwendig.

    Spoiler: 


    Oder doch besser mb_slit und mb_substr verwenden? Und muss man dann mit mb_strlen dran oder kann ich escapen und dann strlen verwenden? Vielleicht siehst Du was ich meine.



    Irgendwann findet jemand einen Fehler in deinem php-Hash und schon sind Millionen Seiten angreifbar.
    Bitte, bitte, bitte, bevor Du sowas schreibst und damit noch andere auf die Idee bringst eigene Crypto zu implementieren, lies Dir doch zumindest die Funktionsbeschreibung von password_hash durch.

    Bei einem selbst programmierten Hash-Algorithmus (bzw. selbst verwaltetenden Papper und Salt) müsste man meine Seite schon gezielt und ausgesprochen mühselig gezielt angreifen.
    Mit einer solchen Aussage verbrennst Du jedwede Dir zugesprochene Kompetenz im ITSec Bereich.
    Wenn es um einen "einfachen" Online Angriff auf Deine Authentifizierung geht, dann brauchst Du weder Salt noch Pepper. Dann reicht schon fast md4.
    Mit keinem noch so ausgeklügeltem Algo kannst Du Layer8 Weakness abfangen.

    In meinen Augen nimmst Du den falschen Ansatz. Der richtige (in meinen Augen) ist:
    Wenn jemand alle Daten hat, also komplette DB und alle Files, ist es mir als Seitenbetreiber trotzdem möglich strukturell dafür Sorge zu tragen, dass der Leak meine User nicht gefährdet? Auch wenn diese so grob fahrlässig sind und für jeden Dienst im WWW das selbe PW verwenden.
    Und da ist es egal wie Du pfefferst und salzst. Da kommt es darauf an, wie der Rechenaufwand der von Dir verwendeten Hashfunktion ist.
    MD5 ist an diese Punkt eine schlechte Wahl.
    Wie schonmal geschrieben, wurde MD5 nicht für Passwordhashing kreiert.
    https://tools.ietf.org/html/rfc1321
    The MD5 algorithm is intended for digital signature applications, where a large file must be "compressed" in a secure manner before being encrypted with a private (secret) key under a public-key cryptosystem such as RSA.
    Dazu auch ganz nett:
    http://ieeexplore.ieee.org/document/6653658/ (DOI: 10.1109/INTECH.2013.6653658 allerdings schon 4 Jahre alt, daher noch etwas Upscaling notwendig, wenn man bedenkt dass heutige GPUs schon 200GH/s schaffen) ....mal was anderes, seit wann ist sci-hub unter "la" TLD?

  2. #22
    Mitglied Avatar von doc-mabuse
    Registriert seit
    Nov 2008
    Beiträge
    2.024
    Danksagungen
    136

    Standard Re: Gulli:Board gehackt -- aus dem Feedback

    Zitat Zitat von braegler Beitrag anzeigen
    Wenn dem so ist, musst Du den PW-String ja erstmal zerlegen. Also entweder in einzelne Chars (str_split) oder Substrings (substr).
    Also schon die erste Stringfunktion notwendig.
    Ja, und?
    Ich bin jetzt nicht der php-Papst, in JavaScript würde das etwa so aussehen:

    hashwert = pw.substring(0,2) + pepper + pw.substring(2,4) + salt + pw.substring(4)

    Wo siehst du da jetzt ein Problem? Oder gar eine Sicherheitslücke?

    Bitte, bitte, bitte, bevor Du sowas schreibst und damit noch andere auf die Idee bringst eigene Crypto zu implementieren, lies Dir doch zumindest die Funktionsbeschreibung von password_hash durch.
    < seufz >
    Poste mal nen Link, dann mach ich das vieleicht.
    Ich seh jetzt nur nicht, wieso du das einforderst: Egal, was da drin steht, die Funktion ist standardisiert, macht also auf allen Installationen das gleiche. Und wenn da ein Fehler drin stecken sollte, den man erst in ein paar Monaten/Jahren findet, dann macht dieser Fehler Millionen von Installationen angreifbar.
    Daran wird sich nichts ändern, wenn ich mir die Funktionsbeschreibung durchlese...

    Mit einer solchen Aussage verbrennst Du jedwede Dir zugesprochene Kompetenz im ITSec Bereich.
    < grins >
    Wo hab ich mir die zugesprochen?


    Wenn es um einen "einfachen" Online Angriff auf Deine Authentifizierung geht, dann brauchst Du weder Salt noch Pepper. Dann reicht schon fast md4.
    Mit keinem noch so ausgeklügeltem Algo kannst Du Layer8 Weakness abfangen.
    Alter, du machst mich bekloppt.
    Das Angriffsszenario ist doch hier ganz klar definiert:
    Irgendjemand hat die komplette Datenbank mit allen Benutzernamen, Passworthashes und ggf. Salts erbeutet.
    Nicht mehr und nicht weniger.

    In meinen Augen nimmst Du den falschen Ansatz. Der richtige (in meinen Augen) ist:
    Wenn jemand alle Daten hat, also komplette DB und alle Files,
    Hat er aber nicht! Hier geht es ganz eindeutig um einen Datenbank-Dump!
    Alle Files abzugreifen ist noch um einiges schwerer als "nur" den SQL-Server zu hacken.

    /QUOTE]ist es mir als Seitenbetreiber trotzdem möglich strukturell dafür Sorge zu tragen, dass der Leak meine User nicht gefährdet? Auch wenn diese so grob fahrlässig sind und für jeden Dienst im WWW das selbe PW verwenden.[/QUOTE]
    Da hast du im Prinzip völlig recht.

    Allerdings würde ich mir in solchen Fällen eine differenzierte Warnung wünschen, wie
    "Diejenigen unter euch, die schwache Passwörter benutzen, und die auch noch für andere Zwecke/Boards benutzen, sollten diese dort sicherheitshalber ändern!"

  3. #23
    Mitglied

    (Threadstarter)


    Registriert seit
    Oct 2004
    Beiträge
    2.369
    Danksagungen
    19

    Standard Re: Gulli:Board gehackt -- aus dem Feedback

    hashwert = pw.substring(0,2) + pepper + pw.substring(2,4) + salt + pw.substring(4)

    Wo siehst du da jetzt ein Problem? Oder gar eine Sicherheitslücke?
    Ist substr Multibyte fest? Wie sieht es mit String-Concats aus, die einerseits Multibyte Strings haben, andererseits durch non-mb-Funktionen verwurstet werden.
    Daher ja: Dieses Vorhaben birgt unter PHP eine (mehrere) gewaltige Sicherheitslücke(n).
    Deshalb auch der Links zum Adventskalender

    Ich seh jetzt nur nicht, wieso du das einforderst: Egal, was da drin steht, die Funktion ist standardisiert, macht also auf allen Installationen das gleiche. Und wenn da ein Fehler drin stecken sollte, den man erst in ein paar Monaten/Jahren findet, dann macht dieser Fehler Millionen von Installationen angreifbar.
    Verstehe nicht ganz, wieso Du einen Link brauchst, aber OK: http://php.net/manual/de/function.password-hash.php
    Also einfach mal lesen, was PWH macht, dann wird Dir gleich klar werden, wieso Du falsch liegst.

    Alter, du machst mich bekloppt.
    Das Angriffsszenario ist doch hier ganz klar definiert:
    Irgendjemand hat die komplette Datenbank mit allen Benutzernamen, Passworthashes und ggf. Salts erbeutet.
    Nicht mehr und nicht weniger.
    EIN Angriffsszenario ist definiert. Nur genau eines.
    Jetzt ist die Anforderung an eine gute PW Hash Funktion nunmal nicht Security by Obscurity (genau das ist das verwenden einer seit 9 Jahren als gebrochen geltender Verhashung, da kannst Du salzen und pfeffern wie Du willst.

    Hat er aber nicht! Hier geht es ganz eindeutig um einen Datenbank-Dump!
    Alle Files abzugreifen ist noch um einiges schwerer als "nur" den SQL-Server zu hacken.
    Achso, dann sind die ganzen Disclosures, wo beschrieben wird wie man von VBB Files abzieht natürlich bullshit. Mea culpa.

    Was Du beschreibst ist das grösste Übel in der Crypto. Wenn die Sicherheit durch das Geheimhalten des Algos Bestand hat, hast Du keine Sicherheit.

  4. #24
    Mitglied Avatar von doc-mabuse
    Registriert seit
    Nov 2008
    Beiträge
    2.024
    Danksagungen
    136

    Standard Re: Gulli:Board gehackt -- aus dem Feedback

    Zitat Zitat von braegler Beitrag anzeigen
    Ist substr Multibyte fest? Wie sieht es mit String-Concats aus, die einerseits Multibyte Strings haben, andererseits durch non-mb-Funktionen verwurstet werden.
    Kannst du das vieleicht auch im Klartext anmerken?
    Was soll in diesem Zusammenhang "Multibyte" bedeuten?
    Ich weiß, das viele Programmierer nur noch Quick-and-Dirty arbeiten. Ich gehöre nicht dazu. In Allgemeinen gibt es eine mehr oder weniger strikte Passwort-Policy, und natürlich wird (/sollte) eine Passworteingabe überprüft werden.

    Passwörter (egal, ob bei Erstellung eines Accounts oder beim Einloggen) < 8 Zeichen werden
    • verworfen.
    • Passwörter > 20 Zeichen werden verworfen.
    • Passwörter mit Zeichen außerhalb des gültigen Bereiches (ASCII 33 - 129) werden verworfen.


    Daher: Nein. Ich sehe da keine Sicherheitslücken.

    Verstehe nicht ganz, wieso Du einen Link brauchst,
    Weil ich die Funktion nicht kenne.
    [/QUOTE]Also einfach mal lesen, was PWH macht, dann wird Dir gleich klar werden, wieso Du falsch liegst.[/QUOTE]
    Öhm. Nein, mir ist nicht klar, weiso ich falsch liege.
    Klar, die Funktion generiert derzeit 60-Byte-Hashes und sollte damit gegen gezielte Angriffe sicherer sein als MD5 - aber ungezielte Angriffe, wie von dir vorgeschlagen, funktionieren mit dieser Funktion genauso wie mit MD5 (wenn wir mal von dem vermutlich etwas höheren Rechenaufwand zur Erstellung dieses Hashes gegenüber MD5 absehen)


    Was Du beschreibst ist das grösste Übel in der Crypto. Wenn die Sicherheit durch das Geheimhalten des Algos Bestand hat, hast Du keine Sicherheit.
    Ja, das hab ich schon oft gehört.
    Praktisch funktioniert das aber ganz hervorragend.

  5. #25
    Mitglied

    (Threadstarter)


    Registriert seit
    Oct 2004
    Beiträge
    2.369
    Danksagungen
    19

    Standard Re: Gulli:Board gehackt -- aus dem Feedback

    Kannst du das vieleicht auch im Klartext anmerken?
    Was soll in diesem Zusammenhang "Multibyte" bedeuten?
    Jetzt wirklich? Ist das jetzt echt Dein Ernst? Du schreibst hier von Sicherheit eines PHP Systems und bist mit der Begrifflichkeit des multibyte Strings überfordert? (Kleiner Hinweis zur Recherche: ASCII -> UFT8 -> UTF32)

    While there are many languages in which every necessary character can be represented by a one-to-one mapping to an 8-bit value, there are also several languages which require so many characters for written communication that they cannot be contained within the range a mere byte can code (A byte is made up of eight bits. Each bit can contain only two distinct values, one or zero. Because of this, a byte can only represent 256 unique values (two to the power of eight)). Multibyte character encoding schemes were developed to express more than 256 characters in the regular bytewise coding system.

    Passwörter (egal, ob bei Erstellung eines Accounts oder beim Einloggen) < 8 Zeichen werden
    verworfen.
    Passwörter > 20 Zeichen werden verworfen.
    Passwörter mit Zeichen außerhalb des gültigen Bereiches (ASCII 33 - 129) werden verworfen.
    Daher: Nein. Ich sehe da keine Sicherheitslücken.
    Ich habe ganz ganz selten schlechtere Sicherheitskonzepte gesehen. Die gefährlichen Steuerzeichen erlaubst Du (46,47,59,95, 96...), beschneidest ein PW auf maximal 20 Zeichen... da fehlt nur noch, dass Du dafür Sorge trägst, dass man das PW nicht ins Eingabefeld pasten kann und der Hash per Backtick auf der Console berechnet wird.
    Spätestens wenn Du den String splittest um dein abstruses Salt-Konstrukt zu erstellen, hat ein versierter Angreifer den Fuss in der Türe (ausser natürlich Du lässt es Sanitizen und nur auf noch alphanumerisch eindampfen).


    Klar, die Funktion generiert derzeit 60-Byte-Hashes und sollte damit gegen gezielte Angriffe sicherer sein als MD5 - aber ungezielte Angriffe, wie von dir vorgeschlagen, funktionieren mit dieser Funktion genauso wie mit MD5
    Nicht gelesen oder nicht verstanden was genau die password_hash Funktion macht. Geschweige denn die Funktion password_verify.


    Daher von der PHP Seite:
    Hinweis:
    It is recommended that you should test this function on your servers, and adjust the cost parameter so that execution of the function takes approximately 0.1 to 0.5 seconds. The script in the above example will help you choose a good cost value for your hardware.
    Also Faktor 20 Milliarden (sorry hatte erst Billion da stehen, hab deutlich zu viel Kontakt zu den Amis), also fast das Selbe..... meine Güte, möchtest Du uns nicht ein paar IoT Devices programmieren, dann haben es die Botnet Betreiber einfacher.........
    Und dann hast Du erst keinen Treffer zu erwarten.

    Spoiler: 


    Einfach mal "test" ein paar mal gehasht:
    PHP-Code:
    echo password_hash("test",PASSWORD_BCRYPT);
    $
    2y$10$YgGUbBwVZ7SxtDb6cSNTDe4PnAKbLyT.wIMKHV2kdS.HQ.Zm7HE6q
    echo password_hash("test",PASSWORD_BCRYPT);
    $
    2y$10$rgaNcVY2Y.dyfn1go1nc1eCyTgKNOHNCjhPYF5EQqamY3DYNYIEQO
    echo password_hash("test",PASSWORD_BCRYPT);
    $
    2y$10$YHSm1ykKDmI/Z/ghmUhATO.iqLpaaibBqluVAAU4fSDwg2ZEMqbQu
    echo password_hash("test",PASSWORD_BCRYPT);
    $
    2y$10$33K1Is5fTYa5Za6VIyLxTe8W8s3A0MoKglJL1PWvXSPL9RwUER/XK
    echo password_hash("test",PASSWORD_BCRYPT);
    $
    2y$10$GsGlOR0a5ZyMpumv/7nqV.Hn20YIHr5CkrtDMNZC/5UcD6JRfG03i
    echo password_hash("test",PASSWORD_BCRYPT);
    $
    2y$10$Kugw7ZZv7IBeOs6yfJuofeXinCrZ7m8mI9Ms87dJ.3XrMmsMOjd0u
    echo password_hash("test",PASSWORD_BCRYPT);
    $
    2y$10$tPid.0r/NYa3mmjnRPUsL.MgvDPKMo5ZCIhdoU7LQTcH3Yer80W7.
    echo 
    password_hash("test",PASSWORD_BCRYPT);
    $
    2y$10$tKjnQe5bq7/UzTBwntdXd.ZiuuxfXBfUuCwiJQOsAt1T94Iu8PVZO
    echo password_hash("test",PASSWORD_BCRYPT);
    $
    2y$10$ZzXkG2YA4O8hHDAWuPwWOuVSShEy5dNUKx.77YhEq3hxfa4pvn1nG
    echo password_hash("test",PASSWORD_BCRYPT);
    $
    2y$10$1ugtBjVB3khLDBUmULTjPO2MbFyDe0USlPu.9SF4x4HI37B0muiCK
    echo password_hash("test",PASSWORD_BCRYPT);
    $
    2y$10$IkHwpXAfDTZD8ykYI7N2Ju/9/RtGgN2Q4FDJ4BeDOcIw/7FzmwcGW
    echo password_hash("test",PASSWORD_BCRYPT);
    $
    2y$10$9EcA0nj8JIDnhQ.HE5SNKuVaZa1QSJXk081jjaRUxabdI.nKAS2NS
    echo password_hash("test",PASSWORD_BCRYPT);
    $
    2y$10$eesS667Jfk0Ue4x7/e6HpunDcRK8Uy8b3YOnbnkH5/WsKpYcad4g.
    echo 
    password_hash("test",PASSWORD_BCRYPT);
    $
    2y$10$ulQ6q6mrOKfWVLVk0dh5EOYlqGrIJd4tnPUoPr47sTwHVAaihzUVW
    echo password_hash("test",PASSWORD_BCRYPT);
    $
    2y$10$XMSvF2BR3wIRbm0HhEBJv.p/jH/BJ848QdxGuiEqpRjMaXxO2TwQe
    echo password_hash("test",PASSWORD_BCRYPT);
    $
    2y$10$HJunqJLmGtDXLnyw0jSthezappFxujdv4Fh89dsjU/muSw5r0Kc.


    Ja, das hab ich schon oft gehört.
    Praktisch funktioniert das aber ganz hervorragend.
    Stimmt. Deswegen hat man auch NOCH nie von irgendwelchen Leaks gehört.

    Sorry Du disqualifizierst Dich hier nur noch, aber das ziemlich deftig.

    Nachtrag:
    Und wie bekommst Du bei einer Beschränkung der Länge der Passworteingabe dann solche Dinge hin???

    Kleiner Tipp (bombensichere Passwörter sind ganz einfach):
    Nimm irgendwas einfaches (Name der Freundin) plus Einsatzzweck.
    Berechne davon dem MD5-Hash und nimm den als Passwort:
    Petra@ebay = cc5cfd638870ac0160a658768c0d4b46
    ...
    Geändert von braegler (04. 01. 2018 um 20:13 Uhr)

  6. #26
    Mitglied Avatar von doc-mabuse
    Registriert seit
    Nov 2008
    Beiträge
    2.024
    Danksagungen
    136

    Standard Re: Gulli:Board gehackt -- aus dem Feedback

    Zitat Zitat von braegler Beitrag anzeigen
    Jetzt wirklich? Ist das jetzt echt Dein Ernst? Du schreibst hier von Sicherheit eines PHP Systems und bist mit der Begrifflichkeit des multibyte Strings überfordert? (Kleiner Hinweis zur Recherche: ASCII -> UFT8 -> UTF32)
    Ich verstehe immer noch nicht, was du mir damit sagen willst:
    1. Du redest von php - ich hab nie von php gesprochen. Nur zu deiner INformation: es gobt auch andere Script-Sprachen.
    2. Willst du mir ernsthaft sagen, das man php nicht klarmachen kann, das dies ein UTF-8-Striing ist, bleiben soll, und alle Operationen nur im UTF-8-Raum durchgeführt werden sollen?
    3. Selbst wenn php eigenmächtig auf UTF-32 erweitert... Willst du mir sagen, das dabei undefinierte Zustände auftreten, oder simple Stringfunktionen unter php dann nicht sicher sind? Dann hast du mir gerade erklärt, warum ich niemals php lernen werde...



    Ich habe ganz ganz selten schlechtere Sicherheitskonzepte gesehen. Die gefährlichen Steuerzeichen erlaubst Du (46,47,59,95, 96...),
    Wenn du da ein Problem siehst, dann lasse die halt nicht zu.
    In meinen Passwörtern kommen die hin und wieder mal vor - und es hat noch nie Probleme gegeben. Von daher gehe ich mal davon aus, das intelligente Programmierer hier entsprechende Sicherheitsmaßnahmen treffen.

    beschneidest ein PW auf maximal 20 Zeichen...
    Dann lass halt mehr zu. Ich hab anfangs meinen Passwort-Hash auf 16 Zeichen komprimiert - und auf meheren Seiten Probleme gehabt, weil die nur 12 zulassen.
    Ich denke auch, 20 Zeichen sind mehr als ausreichend (Wenn man die gängigen Regeln mid. ein Großbuchstabe, Ziffer und Sonderzeichen dazu nimmt).

    Einfach mal "test" ein paar mal gehasht:
    Jo.
    Das Ding arbeitet also automatisch mit Salt... wie aufregend.
    Nachtrag:
    Und wie bekommst Du bei einer Beschränkung der Länge der Passworteingabe dann solche Dinge hin???
    Lies den ganzen Text, dann verstehts du es (vieleicht).




    /Edit:
    Ich muss mich korrigieren.
    Hab mir gerade nochmal mein Passwort-Generator-Script angesehen.
    Alle potentiell gefährlichen Sonderzeichen (39, 42, 44, 47 ... 92, 94, 95, 96) werden durch andere ersetzt.
    Sorry, aber das Script hab ich vor 10 Jahren geschrieben...
    Geändert von doc-mabuse (08. 01. 2018 um 11:21 Uhr)

  7. #27
    Mitglied Avatar von doc-mabuse
    Registriert seit
    Nov 2008
    Beiträge
    2.024
    Danksagungen
    136

    Standard Re: Gulli:Board gehackt -- aus dem Feedback

    vertan.

  8. #28
    Mitglied

    (Threadstarter)


    Registriert seit
    Oct 2004
    Beiträge
    2.369
    Danksagungen
    19

    Standard Re: Gulli:Board gehackt -- aus dem Feedback

    Ich verstehe immer noch nicht, was du mir damit sagen willst:
    1)Du redest von php - ich hab nie von php gesprochen. Nur zu deiner INformation: es gobt auch andere Script-Sprachen.
    2)Willst du mir ernsthaft sagen, das man php nicht klarmachen kann, das dies ein UTF-8-Striing ist, bleiben soll, und alle Operationen nur im UTF-8-Raum durchgeführt werden sollen?
    3)Selbst wenn php eigenmächtig auf UTF-32 erweitert... Willst du mir sagen, das dabei undefinierte Zustände auftreten, oder simple Stringfunktionen unter php dann nicht sicher sind? Dann hast du mir gerade erklärt, warum ich niemals php lernen werde...
    1) Naja, vBulletin ist nunmal in PHP geschrieben, und eine Lücke genau dieses Systems wurde ausgenutzt, daher hab ich mich auch auf php gestürzt
    2) Natürlich kannst Du php klarmachen, welchen Charset Du verwendest
    3) Es ist ein Unterschied, ob Du singlebyte oder multibyte Chars verwendest. Entsprechend musst Du auch andere Funktionen verwenden

    Die selbse Problematik gibt es unter Javascript ja ebenso.
    Einfachstes Beispiel:
    Code:
    'A'.length // U+1D400 MATHEMATICAL BOLD CAPITAL A
    2

    Spoiler: 

    Musste leider ein gewöhnliches A draus machen, da sonst der Rest des Posts nicht gespeichert wird.
    Es gibt doch noch VBulletin Installationen die nicht komplett Multibyte tauglich sind.
    Wer hätte das gedacht?!?

    Deshalb gibt es auch so nette Dinge wie
    Code:
    punycode.ucs2.decode
    Aber da erzähl ich Dir sicher nichts Neues, oder?
    Kannst Du mir eine Skriptsprache nennen, die da durch und durch so konzipiert ist, dass man die selben Standard Funktionen auf ASCII (1byte) und UTF8 (bis zu 4 byte) loslassen kann? Würde mich echt interessieren, ist mir nämlich noch nicht untergekommen. Und da all meine Projekte internationale Gäste haben, wurde ich praktisch dazu gezwungen darin firm zu sein.


    In meinen Passwörtern kommen die hin und wieder mal vor - und es hat noch nie Probleme gegeben. Von daher gehe ich mal davon aus, das intelligente Programmierer hier entsprechende Sicherheitsmaßnahmen treffen.
    Also eine unnötige Gefahrenstelle aufzureissen nur um dann entsprechende Sicherheitsmassnahmen treffen zu können / müssen, ist nun nicht unbedingt ein Indikator für einen intelligenten Programmierer. Best practice ist nunmal das PW unverwurstet an password_hash zu übergeben (resp. password_verify).

    Ich denke auch, 20 Zeichen sind mehr als ausreichend (Wenn man die gängigen Regeln mid. ein Großbuchstabe, Ziffer und Sonderzeichen dazu nimmt).
    Gibt es irgendeinen GUTEN Grund dafür, eine Passworteingabe deutlich unterhalb der maximalen Post-Grösse zu limitieren?
    Und selbst wenn 20 Zeichen heute noch als genügend gelten, gibt es doch Passwort-Manager, die 32 Zeichen und mehr verwenden (können). Da sollte es schon einen sehr vernünftigen Hintergrund haben, wenn man die Sicherheit der Authentifizierung so einschränkt.

    Jo.
    Das Ding arbeitet also automatisch mit Salt... wie aufregend.
    Naja, da ich Deine Telefonnummer nicht hab und es Dir daher nicht vorlesen kann, hab ich darauf vertraut, dass Du den Link aufmachst und mehr als nur die Überschrift liest. So kann man sich täuschen.

    Lies den ganzen Text, dann verstehts du es (vieleicht).
    Sorry, ich sehe Deinen Vorschlag, PWs wie folgt zu generieren und dann zu nutzen:

    Kleiner Tipp (bombensichere Passwörter sind ganz einfach):
    Nimm irgendwas einfaches (Name der Freundin) plus Einsatzzweck.
    Berechne davon dem MD5-Hash und nimm den als Passwort:
    Petra@ebay = cc5cfd638870ac0160a658768c0d4b46
    Jetzt ist
    a) der MD5 Hash 32 Zeichen lang und passt somit NICHT in ein auf 20 Zeichen limitiertes PW Feld

    Spoiler: 

    und
    b) haben wir die Entropie der Passwortelemente auf ganze 16 Zeichen beschränkt.


    Da musst Du mir schon helfen und erklären, wie ich ein 32stelliges PW verwenden soll, wenn der Programmierer (aus irgendwelchen Gründen, die anno 90 vielleicht noch Sinn machten) die Länge auf 20 Zeichen beschränkt.

    Natürlich hab ich Deinen Satz
    Ich hab noch eine kleine Suchen- und Ersetzen-Funktion drumherum gepackt, damit die Sache auf 12 Zeichen incl. Großbuchstaben und Sonderzeichen hinausläuft.
    gelesen. Aber Du hast mir vorgeschlagen meine PWs so (oder so ähnlich) zu generieren und zu verwenden.
    Dass ich erstnoch irgendein JS Schwachsinn drüber schicken soll stand nicht da.

    Alle potentiell gefährlichen Sonderzeichen (39, 42, 44, 47 ... 92, 94, 95, 96) werden durch andere ersetzt.
    Und wieder implementiert man Sicherheitsmassnahmen um ein Problem zu mitigieren, dass man nur hat, weil man denkt ein eigenes "Sicherheitskonstrukt" erstellen zu müssen.

    Aber ganz ehrlich: Egal welche Scriptsprache: Wer heute noch MD5 verwendet (das laut Vorstellungs RFC nie für PW Hashing gedacht war) um PWs zu hashen und diese Hashs zu speichert, sei es mit Salz oder ohne, hat den Schuss nicht gehört.
    Das Du nun Dein 10 Jahre altes Paradigma ausgräbst macht es nicht besser...damals galt RC4 noch als Sicher, solange man die 256byte der Streamchiffre verwirft. Das waren noch Zeiten.... Allerdings galt auch da MD5 schon als gebrochen (seit 2004).
    Geändert von braegler (08. 01. 2018 um 16:59 Uhr)

  9. #29
    Mitglied Avatar von doc-mabuse
    Registriert seit
    Nov 2008
    Beiträge
    2.024
    Danksagungen
    136

    Standard Re: Gulli:Board gehackt -- aus dem Feedback

    Zitat Zitat von braegler Beitrag anzeigen
    3) Es ist ein Unterschied, ob Du singlebyte oder multibyte Chars verwendest. Entsprechend musst Du auch andere Funktionen verwenden
    Na, also.
    Wenn ich single-Byte verwende, fallen also der Groißteil der von dir angesprochenen Probleme weg?

    Und da all meine Projekte internationale Gäste haben, wurde ich praktisch dazu gezwungen darin firm zu sein.
    Ja, aber damit meinst du doch beispielsweise die Beiträge in einem Board?
    Ich seh keinen Grund, alle möglichen Zeichen in einem Passwort zuzulassen. Fast alle mir bekannten Passwortabfragen beschränken den Zeichensatz ([A-Z;a-z;0-9] + Sonderzeichen). Ergo reicht hier UTF-8 oder ASCII völlig aus.


    Also eine unnötige Gefahrenstelle aufzureissen nur um dann entsprechende Sicherheitsmassnahmen treffen zu können / müssen, ist nun nicht unbedingt ein Indikator für einen intelligenten Programmierer.
    Moment!
    Entweder die Funktionen sind so sicher, das nichts passieren kann - dann frage ich mich, wovon wir hier überhaupt reden.
    Oder es gibt potentielle Probleme (Escape-Sequenzen, Injections oder was weiß ich), dann sollte ein halbwegs verantwortungsbewusster Programmierer hier immer ein paar Sicherheitsmechanismen einbauen, egal, worum's geht.

    Best practice ist nunmal das PW unverwurstet an password_hash zu übergeben (resp. password_verify).
    Wieso verbieten dann die Mehrzahl aller Seiten Zeichen, die in URLs oder Dateipfaden vorkommen?

    Gibt es irgendeinen GUTEN Grund dafür, eine Passworteingabe deutlich unterhalb der maximalen Post-Grösse zu limitieren?
    Und selbst wenn 20 Zeichen heute noch als genügend gelten, gibt es doch Passwort-Manager, die 32 Zeichen und mehr verwenden (können). Da sollte es schon einen sehr vernünftigen Hintergrund haben, wenn man die Sicherheit der Authentifizierung so einschränkt.
    Die 20 waren doch nur ein Beispiel. Nimmm halt 32 oder 64, wenn dir das mehr zusagt. Aber da es deiner Aussage nach wohl irgendwelche Risiken gibt, würde ich immer ein oberes Limit setzen, um diese zu minimieren.

    Und was "genügend" angeht: https://de.wikipedia.org/wiki/Passwo...ssw%C3%B6rtern
    demnach sind meine 12-stelligen Passwörter nun wirklich als Bombensicher zu betrachten. Das 20-stellige Passwörter nicht mehr sicher sind, werden wir beide wohl eher nicht mehr erleben.


    a) der MD5 Hash 32 Zeichen lang und passt somit NICHT in ein auf 20 Zeichen limitiertes PW Feld
    und
    b) haben wir die Entropie der Passwortelemente auf ganze 16 Zeichen beschränkt.
    Das ist die Frage, wie man das liest. Einen 32-Zeichen langen Hex-Code könnte man durchaus auch als 16-stelligen Byte-Code lesen. Dann passt er in das Feld und die Entropie liegt bei 256.

    Zugegeben: nur theoretisch (oder würdest du das so an password_hash übergeben?).
    Die Steuerzeichen, Sonderzeichen für Pfade und URLs sowie alle oberhalb von 127 sollte der geneigte Programmierer ja sperren bzw. durch "normale" Zeichen ersetzen. Aber dann bleibt immer noch ein 16-stelliges Passwort mit einer 96er-Entropie übrig. So hatte ich das (/damit meine ich meinen Passwort-Generator) anfangs auch programmiert, aber es gab eine oder zwei Seiten, denen 16-stellige Passwörter zu lang waren, darum hab's ich's später auf 12 Stellen reduziert.

    Und wieder implementiert man Sicherheitsmassnahmen um ein Problem zu mitigieren, dass man nur hat, weil man denkt ein eigenes "Sicherheitskonstrukt" erstellen zu müssen.
    Ich bitte um Entschuldigung, da hab ich mich wohl ungeschickt ausgedrückt.
    Das meinte in nicht in Passwort-Abfragen oder -bearbeitungen. Das hab ich so in meinen Passwort-Generator implementiert, weil viele Seiten die Sonderzeichen aus Pfaden und URLs nicht zulassen.

  10. #30
    Mitglied
    Registriert seit
    Mar 2013
    Beiträge
    178
    Danksagungen
    23

    Standard Re: Gulli:Board gehackt -- aus dem Feedback

    Meiner ist viiiiel länger.

  11. #31
    Mitglied

    (Threadstarter)


    Registriert seit
    Oct 2004
    Beiträge
    2.369
    Danksagungen
    19

    Standard Re: Gulli:Board gehackt -- aus dem Feedback

    Wenn ich single-Byte verwende, fallen also der Groißteil der von dir angesprochenen Probleme weg?
    und gleich danach
    Ergo reicht hier UTF-8 oder ASCII völlig aus.
    UTF8 ist NICHT singlebyte (nur das Subset der US-ASCII innerhalb von UTF8 ist singlebyte).
    Klar, erzähl Du mir ruhig was von Security

    Aber hey, wieso soll man auch nicht alle User die kein Ascii-Zeichensatz verwenden aussperren?
    Sind ja nur 30% der Weltbevölkerung (oder soll der nette Chinese etwa extra für Deine gammlige Seite seinen Charsetz ändern, damit er ein Passwort dass Di beliebt wählen kann?


    Entweder die Funktionen sind so sicher, das nichts passieren kann - dann frage ich mich, wovon wir hier überhaupt reden.
    Oder es gibt potentielle Probleme (Escape-Sequenzen, Injections oder was weiß ich), dann sollte ein halbwegs verantwortungsbewusster Programmierer hier immer ein paar Sicherheitsmechanismen einbauen, egal, worum's geht.
    Du machst Dich lächerlich, nicht mehr nicht weniger. Du hast keine Ahnung davon, dass UTF8 multibyte ist, würdest dafür sb-Funktionen verwenden und Dich dann wundern, wenn Dein Projekt leaked.
    Ein halbwegs verantwortungsbewusster Programmierer reisst keine Lücken auf wo er sie vermeiden kann.


    Wieso verbieten dann die Mehrzahl aller Seiten Zeichen, die in URLs oder Dateipfaden vorkommen?
    Ich kenne nicht eine einzige grosse Seite, die sowas macht. Nicht eine. (wir reden von PW)

    Bitte nenne mir doch eine Seite (vielleicht aus den Top 100), die eine solche unsinnige Sache macht. Würde mich freuen mich mal mit denen auseinander setzen zu können.

    Zugegeben: nur theoretisch (oder würdest du das so an password_hash übergeben?).
    Natürlich, wie auch z.B. OWASP seit Jahren rät. PW Eingaben ungefiltert an die Hashfunktion. Alles andere reisst unnötige Lücken auf.


    Du solltest da dringend Deine Kenntnisse aufbessern.
    https://www.owasp.org/index.php/Pass...or_credentials


    demnach sind meine 12-stelligen Passwörter nun wirklich als Bombensicher zu betrachten. Das 20-stellige Passwörter nicht mehr sicher sind, werden wir beide wohl eher nicht mehr erleben.
    Du hast ja förmlich den Finger am Puls der Zeit....
    Wieviele TH/s (md5, distributed) hat Ela auf der Blackhat nochmal aus den Webcam-Botnet gelutscht?

  12. #32
    Mitglied Avatar von doc-mabuse
    Registriert seit
    Nov 2008
    Beiträge
    2.024
    Danksagungen
    136

    Standard Re: Gulli:Board gehackt -- aus dem Feedback

    Zitat Zitat von braegler Beitrag anzeigen
    UTF8 ist NICHT singlebyte (nur das Subset der US-ASCII innerhalb von UTF8 ist singlebyte).
    Klar, erzähl Du mir ruhig was von Security
    Na gut, dann beenden wir die Diskussion hiermit...

    Wikipedia:
    UTF-8 (Abk. für 8-Bit UCS Transformation Format, wobei UCS wiederum Universal Character Set abkürzt) ...

    UTF-8 ist in den ersten 128 Zeichen (Indizes 0–127) deckungsgleich mit ASCII und eignet sich mit in der Regel nur einem Byte Speicherbedarf für Zeichen vieler westlicher Sprachen b
    Für jemanden, der anderen immer nur Vorwirft, kein Ahnung zu haben, war das schon ziemlich schwach. Aber gut:
    Du hast Recht und ich hab meine Ruhe.


    Aber ein letztes noch:
    Du hast ja förmlich den Finger am Puls der Zeit....
    Wieviele TH/s (md5, distributed) hat Ela auf der Blackhat nochmal aus den Webcam-Botnet gelutscht?
    Keine Ahnung - sag's doch einfach, statt immer nur mysteriöse Andeutungen zu machen.

    Wenn er die tausendfache-fache Leistung der in Wikipedia angedeuteten 1 Milliarde Schlüssel pro Sekunde schafft, dann wäre mein Passwort nach 19.000 Jahren gebrochen. Bei der millionenfachen Leistung immer noch 19 Jahre. Und mein Passwort hat "nur" 12 Stellen. Da das eine expotenitielle Funktion ist, liegen 20 Stellen immer noch jenseits aller vorstellbaren Rechenleistung.

    Und die Rechenleistung der Computer wird sich in den kommenden Jahren nicht mehr so extrem erhöhen wie bisher, da kommt man so langsam an physikalische Grenzen (wobei ich jetzt mal unterstelle, das Quantencomputer noch ein paar Jahrzehnte lang Theorie bleiben).

    Im Übrigen denke ich nicht, das man aus der Demonstration eines einzelnen, vermutlich Inselbegabten Genies so ohne weiteres auf praktische Anwendbarkeiten schließen sollte.

  13. #33
    Mitglied

    (Threadstarter)


    Registriert seit
    Oct 2004
    Beiträge
    2.369
    Danksagungen
    19

    Standard Re: Gulli:Board gehackt -- aus dem Feedback

    Jaja, die Sache mit dem lesen und verstehen.
    Hast Du in diesem Thread ja schon zum Besten gegeben.
    Aber Du jast Deine Kernkompetenz halt sicher in einem anderen Bereich (fernab der IT)

    Du zitierst, offensichtlich ohne in der Lage zu sein, das zitierte auch zu verstehen.
    Ich mach es Dir mal extra einfacher und entferne die nicht zwingend zur Erkenntnis benötigten Zeichen
    UTF-8 ist in den ersten 128 Zeichen (Indizes 0–127) ..... nur einem Byte Speicherbedarf
    Also 128 von über 4 Millarden Zeichen aus dem UTF-8 Charset sind singlebyte.
    Also muss UTF8 ja singlebyte sein.

    Du behauptest alle Autos seien blau, weil es blaue Autos gibt.
    Also rhetorisch bist Du auf einem Level mit so Profis wie Dobrint und Trump.


    Da bist Du schon auf der Wikipedia, schaffst es aber nicht zu lesen was dort steht:
    Bei der UTF-8-Kodierung wird jedem Unicode-Zeichen eine speziell kodierte Zeichenkette variabler Länge zugeordnet. Dabei unterstützt UTF-8 Zeichenketten bis zu einer Länge von vier Byte, auf die sich – wie bei allen UTF-Formaten – alle Unicode-Zeichen abbilden lassen.
    oder wie ich es ausgedrückt hab
    (nur das Subset der US-ASCII innerhalb von UTF8 ist singlebyte).
    Wenn Du nun keine Ahnung hast, was US-ASCII bedeutet, würde ich Dir wieder Wiki vorschlagen. Aber als Profi weisst Du das sicherlich

    Aber klar, erzähl Du weiter von Deiner abstrusen Security Measurements.

    Und die Rechenleistung der Computer wird sich in den kommenden Jahren nicht mehr so extrem erhöhen wie bisher, da kommt man so langsam an physikalische Grenzen (wobei ich jetzt mal unterstelle, das Quantencomputer noch ein paar Jahrzehnte lang Theorie bleiben).
    Und wieder disqualifizierst Du Dich. Schon die Papers zur Volta-Cuda-Architektur gesehen? Hat im Vollausbau nur 5376 Kerne.....


    Na gut, dann beenden wir die Diskussion hiermit...
    Würde ich auch sagen, hat keinen Wert mit Dir.
    Deine Unkenntnis ist himmelschreiend und innerhalb von Sekunden feststellbar.
    Einigen wir uns: Dein UTF-8 ist singlebyte, denn Du bist was ganz Besonderes.


    Erinnert mich an Klempner.h und spüle für untertischgerät für Gas einbauen
    Geändert von braegler (12. 01. 2018 um 11:20 Uhr)

  14.  
     
     
Seite 2 von 2 ErsteErste 12

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •