sollte sich der öffentliche rsa-exponent aus sicherheitsgründen nur in {3, 5, 17, 257 oder 65537} befinden?
<p>in meinem projekt verwende ich den wert des öffentlichen exponenten von 4451h. ich dachte, es ist sicher und in ordnung, bis ich anfing, eine kommerzielle rsa-verschlüsselungsbibliothek zu verwenden. wenn ich diesen exponenten mit dieser bibliothek verwende, wird eine ausnahme ausgelöst.</p><p>ich habe die entwickler dieser bibliothek kontaktiert und die folgende antwort erhalten: "diese funktion soll einige angriffe auf rsa-schlüssel verhindern. die folge ist, dass der exponentenwert auf {3, 5, 17, 257 oder 65537} begrenzt ist. das deaktivieren dieser prüfung ist wird noch untersucht, da die risiken groß sein können. "</p><p>es ist das erste mal in meinem leben, dass ich höre, dass andere werte als {3, 5, 17, 257 oder 65537} verwendet werden, um rsa zu brechen. ich wusste nur, dass ich 3 verwenden sollte, wenn eine falsche polsterung anfällig ist.</p><p>ist das wirklich so? sicherlich kann ich eine andere bibliothek verwenden, aber nach einer solchen antwort machte ich mir sorgen um die sicherheit meiner lösung.</p>
<p>es ist keine schwäche für einen kurzen oder langen öffentlichen exponenten für rsa bekannt, solange der öffentliche exponent "korrekt" ist (dh relativ prim zu <em> p-1</em> für alle primzahlen <em> p </em> welche den modul teilen).</p><p><em> if</em> sie verwenden einen kleinen exponenten <em> und</em> sie verwenden kein padding für die verschlüsselung <em> und</em> sie verschlüsseln genau dieselbe nachricht mit bei mehreren unterschiedlichen öffentlichen schlüsseln ist ihre nachricht gefährdet: if <em> e = 3</em> und sie verschlüsseln die nachricht <em> m</em> mit öffentlichen schlüsseln <em> n<sub>1</sub></em>, <em> n<sub>2</sub></em> und <em> n<sub>3</sub></em>, dann hast du <em> c<sub>ich</sub> = m<sup>3</sup></em> mod <em> n<sub>ich</sub></em> für <em> i = 1</em> bis <em> 3</em>. mit dem <a href="http://en.wikipedia.org/wiki/chinese\_remainder\_theorem">chinesischer restsatz</a> können sie dann <em> m<sup>3</sup></em> mod <em> n<sub>1</sub>n<sub>2</sub>n<sub>3</sub></em>, was sich als <em> m herausstellt<sup>3</sup></em> (ohne modulo) weil <em> n<sub>1</sub>n<sub>2</sub>n<sub>3</sub></em> ist eine größere ganze zahl. eine (nicht modulare) kubikwurzelextraktion reicht dann aus, um <em> m</em> zu extrahieren.</p><p>die schwäche ist hier <strong> nicht </strong> der kleine exponent; vielmehr ist es die verwendung einer falschen auffüllung (nämlich überhaupt keine auffüllung) für die verschlüsselung. das auffüllen ist für die sicherheit von rsa sehr wichtig, egal ob verschlüsselung oder signatur. wenn sie keine ordnungsgemäße polsterung verwenden (wie die in <a href="http://www.rsa.com/rsalabs/node.asp?id=2125">pkcs # 1</a> beschriebenen), haben sie viele schwächen, und die im obigen absatz beschriebene ist bei weitem nicht die größte. wenn sich jemand jedoch auf eine schwäche im zusammenhang mit der exponentengröße bezieht, bezieht er sich mehr oder weniger direkt auf dieses ereignis. das ist ein bisschen alte und falsche überlieferung, die manchmal in ein verbot gegen <em> groß</em> exponenten umgewandelt wird (da es sich um einen mythos handelt, ist der umgekehrte mythos auch ein mythos und nicht mehr - und nein weniger begründet); ich glaube, das beobachten sie hier.</p><p>es gibt jedoch einige gründe, warum ein großer öffentlicher exponent vermieden werden sollte:</p><ul> <li> <p>kleine öffentliche exponenten fördern die effizienz (für public-key-operationen).</p> </li> <li> <p>es gibt sicherheitsprobleme, wenn ein kleiner exponent <em> privat</em> vorhanden ist. ein schlüsselwiederherstellungsangriff wurde beschrieben, wenn die länge des privaten exponenten nicht mehr als 29% der länge des öffentlichen exponenten beträgt. wenn sie erzwingen möchten, dass der private exponent kurz ist (z. b. um operationen mit privaten schlüsseln zu beschleunigen), müssen sie mehr oder weniger einen großen öffentlichen exponenten verwenden (so groß wie der modul). die forderung, dass der öffentliche exponent kurz sein muss, kann dann als eine art indirekte gegenmaßnahme angesehen werden.</p> </li> <li> <p>einige weit verbreitete rsa-implementierungen drosseln große öffentliche rsa-exponenten. z.b. der rsa-code in windows (cryptoapi, von internet explorer für https verwendet) besteht darauf, den öffentlichen exponenten in einem einzelnen 32-bit-wort zu codieren. es kann keinen öffentlichen schlüssel mit einem größeren öffentlichen exponenten verarbeiten.</p> </li> </ul><p>dennoch sieht "risiken können groß sein" wie die allgemeine rechtfertigung aus ("dies ist ein sicherheitsproblem" ist die übliche art zu sagen "wir haben es nicht implementiert, aber wir wollen keine art von faulheit zugeben").</p>
<blockquote> <p>openssl genrsa -out private.pem gibt mir eine pem-datei, die nur einen privaten schlüssel enthält</p> </blockquote><p>nicht wirklich. im prinzip kann rsa nur einen privaten schlüssel ohne öffentlichen schlüssel speichern, aber das von openssl verwendete rsaprivatekey-format (von pkcs1 alias rfcs 2313 2437 3447 <a href="https://tools.ietf.org/html/rfc8017#appendix-a.1.2">8017</a> ) speichert beide. die für andere asymmetrische algorithmen (dsa, dh, ecc) verwendeten formate haben ebenfalls diese eigenschaft. dies bedeutet, dass sie immer nur die privatekey-datei speichern und bei bedarf den publickey erhalten können. gpg macht das gleiche; die informationen zum öffentlichen schlüssel sind immer im "geheimen" schlüssel enthalten, wie sie aus historischen gründen genannt werden. openssh verwendet (meistens) die openssl-formate, daher ist dies keine nützliche beobachtung.</p><blockquote> <p>openssl rsa -in private.pem -outform pem -pubout -out public.pem gibt mir eine pem-datei, die einen öffentlichen schlüssel enthält</p> </blockquote><p>welches enthält <em> nur </em> den öffentlichen schlüssel. und ist so gut wie nutzlos, weil (1) es aus der privatekey-datei neu generiert werden kann und (2) die meisten anwendungen nicht nur den publickey, sondern stattdessen ein zertifikat verwenden.</p><blockquote> <p>nachdem ich diese beiden befehle ausgeführt habe, habe ich mein rs-256-schlüsselpaar (ist es der richtige name? die schlüssel sind meines wissens 2048 bit, warum also rs-256, nicht rs-2048?).</p> </blockquote><p>technisch gesehen ist es ein schlüsselpaar, aber wie oben führt openssl im grunde das konzept des schlüsselpaars mit dem privaten schlüssel zusammen und unterscheidet nur den öffentlichen schlüssel - der zu unterscheiden ist, weil er öffentlich ist.</p><p>ja, kryptoschlüssel werden fast immer in bits gemessen. der schemaname rs256 (kein bindestrich) wird in json web signature (jws) und json web token (jwt) verwendet, um die rsa-signatur (insbesondere das von pkcs1 definierte rsa-signaturschema rsassa-pkcs1-v1\_5) <em> mit sha zu bezeichnen -256 für den hash </em>. dies hängt nicht mit der größe des rsa-schlüssels zusammen und kann mit jeder (implementierten) größe verwendet werden. der beispielschlüssel für rs256 in rfc7517 ist 1024-bit - obwohl rsa-1024 heute keinen ausreichenden sicherheitsspielraum bietet und von behörden wie nist und cabforum (und damit den meisten webbrowsern) seit mehreren jahren verboten ist. die rsa-signatur (und auch die rsa-verschlüsselung) wird in vielen anderen anwendungen als jws/jwt verwendet.</p><blockquote> <p>kann ich die 2 dateien, die ich (private.pem + public.pem) habe, bereits als zertifikat betrachten?</p> </blockquote><p>zunächst eine klarstellung: 'zertifikat' ist ein allgemeines konzept, das in vielen zusammenhängen verwendet wird. bei krypto sind die interessierenden zertifikate normalerweise public-key-zertifikate, die einen public-key an eine identität (oder manchmal eine rolle) mit einigen verwandten attributen binden, und die mit abstand häufigsten sind die durch <a href="https://en.wikipedia.org/wiki/x.509">definierten public-key-zertifikate x.509</a> , ein standard, der 1988 von der damaligen ccitt (jetzt itu-t) erstellt und seitdem von vielen standardorganisationen verbessert und nützlicher, aber nicht grundlegend anders gemacht wurde. die internetstandards für zertifikate basieren auf x.509 und werden als public key infrastructure unter verwendung von x.509, abgekürzt pkix, bezeichnet. x.509 repräsentiert seine daten wie einige andere computerstandards mithilfe einer generischen syntax namens abstract syntax notation 1, abgekürzt <a href="https://en.wikipedia.org/wiki/abstract\_syntax\_notation\_one">asn.1</a> .</p><p>nachdem dies gesagt wurde, nein. <strong> ein public-key/x.509-zertifikat <em> enthält </em> einen publickey, aber es ist nicht nur ein publickey. </strong> es enthält viele andere informationen, die für die art und weise, wie sie verwendet werden, von entscheidender bedeutung sind, obwohl der öffentliche schlüssel wohl die wichtigste einzelne information ist. ein zertifikat wird <em> für </em> einen öffentlichen schlüssel erstellt, der normalerweise als zertifikatsignierungsanforderung (auch als csr oder einfach als anforderung bezeichnet) von einer entität namens <a href="https://en.wikipedia.org/wiki/certificate\_authority">certificate authority</a> oder ca verpackt wird, die das zertifikat digital signiert den schlüssel der zertifizierungsstelle, damit niemand ihn ändern kann, und somit kann jedes programm, das ihn verwendet, ihm vertrauen. grundsätzlich kann jeder als zertifizierungsstelle fungieren, und insbesondere das openssl-befehlszeilenprogramm kann die technischen vorgänge ausführen, die eine zertifizierungsstelle ausführt, z. b. das ausstellen von zertifikaten. in den meisten situationen hängt der wert und die nützlichkeit eines zertifikats jedoch davon ab, wie gut und umfassend der ausstellenden zertifizierungsstelle vertraut wird. daher sind die erfolgreichsten zertifizierungsstellen diejenigen, die sich als vertrauenswürdig etabliert haben, z. b. digicert (jetzt einschließlich symantec) -verisign, comodo, godaddy usw.</p><p>als sonderfall ist es möglich, ein selbstsigniertes zertifikat zu haben, das mit einem eigenen schlüssel anstelle des schlüssels einer zertifizierungsstelle signiert wird. dieses zertifikat kann kein vertrauen wie eines von einer echten zertifizierungsstelle vermitteln, da es nicht effektiv gegen substitution geschützt ist. es kann jedoch auch dann erstellt werden, wenn sie eine zertifizierungsstelle nicht kontaktieren und/oder bezahlen können, und es kann normalerweise mit verarbeitet werden manuelle genehmigung oder überschreibung durch programme, die normalerweise ein zertifikat verwenden oder erfordern.</p><blockquote> <p>was ist der inhalt von cer-, crt- oder p12-dateien? ich kann keine wirklichen beispiele für diese dateien finden.</p> </blockquote><p>cer und crt werden (beide) häufig als erweiterungen für eine datei mit einem x.509-zertifikat verwendet und können in beiden fällen je nach dateisystem verwendet werden. für den dateiinhalt werden zwei gängige codierungen verwendet: "der", eine von asn.1 definierte binäre codierung (distinguished encoding rules); und <a href="https://en.wikipedia.org/wiki/privacy-enhanced\_electronic\_mail">"pem"</a> , das den binären der in base64 konvertiert, in zeilen mit geeigneter größe unterteilt und mit header- und trailer-zeilen versehen, was für personen bequemer ist, insbesondere für dinge wie ausschneiden und einfügen. pem wird so genannt, weil diese codierung ursprünglich für privacy enhanced (e) mail definiert wurde, ein schema, das von anderen e-mail- und nachrichtentechnologien ersetzt wurde, dieses format jedoch weiterhin verwendet wird. diese codierungen sehen sehr unterschiedlich aus, enthalten jedoch genau dieselben informationen (sofern sie nicht beschädigt sind), und viele programme, die sich mit zertifikaten befassen, können beide lesen. von openssl geschriebene pem-dateien enthalten häufig kommentarinformationen vor dem header oder nach dem trailer. programme sollten dies ignorieren, aber manchmal werden sie verwirrt und sie müssen die überflüssigen informationen entfernen. achten sie unter windows auch darauf, nicht das 'utf-8'-format zu verwenden, das normalerweise ein <a href="https://en.wikipedia.org/wiki/byte\_order\_mark">byte order mark</a> hinzufügt, das auf dem display nicht sichtbar ist, aber ein programm stört, das die datei liest.</p><p>obwohl pem häufig für zertifikate verwendet wird und viele pem-dateien zertifikate sind, sollten sie beachten, dass pem auch für viele andere zwecke verwendet wird. nehmen sie nicht an, dass eine pem-datei ein zertifikat ist. überprüfen sie stattdessen die kopfzeile, in der in diesem fall bequemerweise <code>begin certificate</code> oder manchmal <code>begin x509 certificate</code> steht. siehe <a href="https://tools.ietf.org/html/rfc7468">rfc7468</a> für viel mehr details dazu.</p><p>p12 wird häufig verwendet, um dateien im format <a href="https://tools.ietf.org/html/rfc7292">pkcs12 aka pfx</a> zu identifizieren, was ganz anders ist. obwohl der pkcs12-standard eine große anzahl von optionen unterstützt, wird er normalerweise verwendet, um einen privaten schlüssel plus des entsprechenden zertifikats plus zu enthalten. in den meisten fällen handelt es sich um ein oder mehrere "ketten" - oder "zwischen" -zertifikate, die zur bildung einer vertrauenskette erforderlich sind überprüfen sie das endentitätszertifikat. in der praxis sind pkcs12-dateien immer binär, obwohl es keinen technischen grund gibt, warum sie nicht pem-codiert oder auf andere weise benutzerfreundlicher gemacht werden könnten.</p><blockquote> <p>wie generiere ich cer, crt oder p12 aus meinen 2 pem-dateien, die ich habe?</p> </blockquote><p>um ein zertifikat zu erhalten, müssen sie entweder eine zertifizierungsstelle (entweder eine etablierte oder eine von ihnen erstellte diy) verwenden oder ein selbstsigniertes zertifikat erstellen. je nachdem, welche software (und ggf. ca) sie verwenden, gibt es wahrscheinlich hunderte von variationen, aber für openssl und <em> die meisten </em> cas die <em> üblichen </em> ) verfahren ist:</p><ol> <li>erstellen sie eine csr mit <code>openssl req -new -key privatekey [... other options] &gt;csr</code></li> </ol><p>weitere informationen finden sie in der manpage zu <code>req</code>. wenn sie das zertifikat <em> für ssl/tls einschließlich https </em> verwenden möchten, geben sie als 'common name' den (oder einen) namen an, unter dem auf den server zugegriffen wird. dies ist normalerweise der vollständige name qualifizierter domainname (fqdn). wenn sie das zertifikat für andere anwendungen verwenden möchten, hängen die erforderlichen identitätsinformationen von den anwendungen ab.</p><ol start="2"> <li>senden sie für eine echte zertifizierungsstelle die csr zusammen mit dem identitätsnachweis oder einer anderen autorisierung und möglicherweise der erforderlichen zahlung an die zertifizierungsstelle (häufig auf einem webformular, das pem bequem macht).</li> </ol><p>sie sollten im gegenzug ein neu ausgestelltes 'end-entity'-zertifikat (das ihren öffentlichen schlüssel und ihre identität enthält) und normalerweise ein oder zwei zertifikate mit öffentlichen schlüsseln und identität (en) für zwischenzertifizierungsstellen erhalten, die zum erstellen der vertrauenskette verwendet werden . dies können separate dateien (entweder der oder pem) oder eine verkettung (nur pem) oder ein bestimmter fall des <a href="https://tools.ietf.org/html/rfc2315">pkcs7</a> -standards (signeddata ohne daten oder signaturen, nur zertifikate) sein, die normalerweise als p7b oder p7c bezeichnet werden.</p><p>2 '. oder mach das selbst. erstellen sie einen ca-schlüssel und ein zertifikat (nur einmal) und verwenden sie dann entweder <code>openssl ca ...</code> oder <code>openssl x509 -req -ca -cakey ...</code>, um die csr zu lesen und ein zertifikat unter ihrer eigenen ca auszustellen.</p><p>dieses zertifikat kann nur mit systemen und programmen verwendet werden, die von ihnen selbst gesteuert werden, oder mit personen, die ihnen implizit vertrauen <em> und </em>. sie können ihr ca-zertifikat technisch installieren. dies ist normalerweise eine kleine gruppe, manchmal eine leere einer. achten sie auch darauf, dass sie ihrem ca-zertifikat und dem end-entity-zertifikat nicht denselben namen geben, indem sie beispielsweise die standardeinstellungen in <code>req</code> akzeptieren. wenn sie dies tun, können die resultierenden zertifikate nirgendwo verwendet werden.</p><ol start="3"> <li>verwenden sie das zertifikat nach bedarf zusammen mit dem privaten schlüssel und den kettenzertifikaten. dies <em> kann </em> das kombinieren zu einem pkcs12 unter verwendung von <code>openssl pkcs12 -export</code> beinhalten.</li> </ol><p>wie oben erwähnt, können sie anstelle eines von der zertifizierungsstelle ausgestellten zertifikats ein selbstsigniertes zertifikat erstellen. ersetzen sie die schritte 1 und 2/2 'durch den einzelschritt: <code>openssl req -new -x509 -key privatekey ... &gt;cert</code></p><p>beachten sie das hinzufügen des flags <code>-x509</code>, und auf der manpage werden zahlreiche zusätzliche optionen beschrieben. dies hat alle eigenschaften und einschränkungen einer diy-zertifizierungsstelle sowie mehr: sie (und/oder ihre freunde) können das diy-zertifizierungsstellenzertifikat nicht nur einmal installieren, sondern müssen jedes endentitätszertifikat separat installieren und den vorgang jederzeit wiederholen ihre zertifikate müssen ersetzt werden, da sie ablaufen oder relevante informationen geändert werden.</p><blockquote> <p>ich habe einige informationen gesehen, dass die p12-datei durch ein passwort geschützt werden kann - was ist der grund, diese datei mit einem passwort zu schützen -, dass das passwort erneut irgendwo gespeichert werden muss. wir speichern die p12-datei bereits an einem sicheren ort, auf den niemand zugriff haben sollte nach rechts?</p> </blockquote><p>das passwort muss nicht unbedingt gespeichert werden. programme können bei bedarf dazu auffordern (und das programm <code>openssl</code> tut dies insbesondere). obwohl pkcs12/pfx heute häufig zum speichern verwendet wird, war es ursprünglich für die übertragung eines privaten schlüssels mit zertifikaten von einem system auf ein anderes vorgesehen, ein prozess, der sehr oft nicht sicher ist. selbst für speicher, systeme und orte, die sie für sicher halten, erweisen sich manchmal als nicht sicher, und die gründliche verteidigung der verschlüsselung des privaten schlüssels lohnt sich. aber in einigen fällen ist das passwort nur ein kleines bisschen zusätzliche arbeit ohne wirklichen nutzen.</p><blockquote> <p>ich habe ein beispiel gesehen, in dem 1 pem-datei sowohl öffentliche als auch private schlüssel enthielt. gibt es nicht eine entschiedene struktur von pem? kann ich dort die gewünschten schlüssel ablegen?</p> </blockquote><p>ob mehr als ein objekt aus einer einzelnen pem-datei gelesen und somit sinnvoll in dieser gespeichert werden kann, hängt vom programm ab, das das lesen durchführt. openssl kann in <em> den meisten </em> (aber nicht allen) fällen damit umgehen. daher ist die verwendung solcher dateien mit openssl (und programmen, die die openssl-bibliothek aufrufen) mäßig häufig. andere programme und bibliotheken können unterschiedlich sein. wie oben ist das speichern des öffentlichen schlüssels als solchen fast nie sinnvoll. speichern von z.b. der privatekey und das <em> zertifikat </em> oder alle zertifikate in der kette können nützlich sein. programme wie apache httpd und nginx unterstützen dies (benötigen es jedoch nicht).</p><blockquote> <p>ich sah auch eine pem-datei mit " begin certificate " und " end certificate ". was ist das für ein zertifikat?</p> </blockquote><p>siehe oben für zertifikate im allgemeinen. wenn sie die details eines bestimmten zertifikats wissen möchten (den namen des schlüsselbesitzers, der als "betreff" bezeichnet wird; den öffentlichen schlüssel; den zeitraum, in dem das zertifikat gültig ist; die ausstellende zertifizierungsstelle und seine seriennummer usw.), können sie verwenden <code>openssl x509 -text &lt;file</code> oder abhängig von ihrem system können normalerweise mehrere andere programme zertifizierungsdetails anzeigen. unter windows für <code>.cer .crt</code> können sie einfach auf eine datei doppelklicken (oder sie im dialogfeld 'ausführen' oder im befehl <code>start</code> in cmd benennen), und ein dialogfeld mit einer registerkarte details wird angezeigt.</p> <p>dies wird normalerweise<strong> verursacht durch das versehentliche anbieten mehrerer ssh-schlüssel </strong>zum server. der server weist jeden schlüssel zurück, nachdem zu viele schlüssel angeboten wurden.</p><p>sie können sich davon überzeugen, indem sie das flag <code>-v</code> zu ihrem befehl <code>ssh</code> hinzufügen, um eine ausführliche ausgabe zu erhalten. sie werden feststellen, dass eine reihe von schlüsseln angeboten werden, bis der server die verbindung mit den worten &quot;<em>&quot; zu viele authentifizierungsfehler für [benutzer] &quot;</em>zurückweist. ohne ausführlichen modus wird nur die mehrdeutige meldung<em> &quot;verbindung von peer zurückgesetzt&quot; </em>angezeigt.</p><p>um zu verhindern, dass irrelevante schlüssel angeboten werden, müssen sie dies in jedem host-eintrag in der datei <code>~/.ssh/config</code> (auf dem client-computer) explizit angeben, indem sie <code>identitiesonly</code> wie folgt hinzufügen:</p><pre><code>host www.somehost.com identityfile ~/.ssh/key\_for\_somehost\_rsa identitiesonly yes port 22 </code></pre><p>wenn sie den ssh-agent verwenden, ist es hilfreich, <code>ssh-add -d</code> auszuführen, um die identitäten zu löschen.</p><p>wenn sie keine ssh-hosts-konfiguration verwenden, müssen sie den richtigen schlüssel im befehl <code>ssh</code> wie folgt explizit angeben:</p><pre><code>ssh -i some\_id\_rsa -o 'identitiesonly yes' them@there:/path/ </code></pre><p><em> hinweis: der parameter 'identitiesonly yes' muss zwischen anführungszeichen stehen. </em></p><p>oder</p><pre><code>ssh -i some\_id\_rsa -o identitiesonly=yes them@there:/path/ </code></pre> <p>es ist wahrscheinlich ein versuch, passwörter zu entmutigen, die zu gängigen formaten oder zeichenmasken passen. wenn für eine kennwortrichtlinie die verwendung einer nummer erforderlich ist, setzen viele personen ihre nummer am ende eines wortes oder von wörtern. hier einige beispiele aus unternehmensumgebungen:</p><ul> <li> <a href="http://passwordresearch.com/stats/statistic397.html">netspi top password masks für 2015</a> </li> <li> <a href="http://passwordresearch.com/stats/statistic376.html">2015 trustwave global security report - kennwortmasken</a> </li> </ul><p>angreifer mögen diese benutzergewohnheit, weil sie das knacken oder erraten von hybrid-passwörtern erleichtert. sie können sich darauf konzentrieren, wortlisten mit am ende hinzugefügten zahlen zu kombinieren, anstatt einen zeitaufwändigeren brute-force-ansatz zu wählen.</p><p>einige organisationen implementieren eine solche richtlinie, um die sicherheit zu verbessern, indem benutzer dazu gebracht werden, ihre nummern einzugeben. dies ist ein weniger vorhersehbarer ort. es hört sich so an, als würden sie dies in ihrer situation nicht mit einer anderen komplexitätsprüfung kombinieren und stattdessen alle passwörter ablehnen, die mit einer zahl enden, unabhängig davon, wie zufällig sie ansonsten sind. das ist keine sehr gute möglichkeit, diese art der überprüfung zu implementieren, aber sie sind mit diesem ansatz nicht allein.</p> <p>zunächst einmal würde ich mich nicht als sicherheitsexperte bezeichnen, aber ich war in der lage, diese frage beantworten zu müssen. was ich herausgefunden habe, hat mich ein bisschen überrascht: <em> es gibt kein vollständig sicheres system</em>. nun, ich denke, ein völlig sicheres system wäre eines, bei dem alle server ausgeschaltet sind :)</p><p>jemand, der damals mit mir zusammenarbeitete, beschrieb das entwerfen eines sicheren systems in bezug auf <em> die messlatte höher legen</em> für eindringlinge. jede sicherungsebene verringert also die möglichkeit eines angriffs.</p><p>selbst wenn sie beispielsweise den privaten schlüssel perfekt sichern könnten, ist das system nicht <em> vollständig</em> sicher. die korrekte verwendung der sicherheitsalgorithmen und die aktualisierung der patches legen jedoch die messlatte höher. aber ja, ein supercomputer, der leistungsfähig genug ist und genügend zeit hat, kann die verschlüsselung unterbrechen. ich bin sicher, dass all dies verstanden wird, also werde ich die frage zurückbekommen.</p><p>die frage ist klar, also werde ich zuerst versuchen, jeden ihrer punkte anzusprechen:</p><blockquote> <p>angenommen, der schlüssel ist durch das sicherheitsmodell des dateisystems geschützt. aber was ist mit (böswilligen) superusern oder plattformen, die keine solche wiedergabetreue bieten?</p> </blockquote><p>ja, wenn sie etwas wie <a href="http://msdn.microsoft.com/en-us/library/windows/desktop/bb204778%28v=vs.85%29.aspx">windows key store</a> oder einen kennwortverschlüsselten privaten tls-schlüssel verwenden, sind sie den benutzern ausgesetzt, die über das kennwort (oder den zugriff) auf die privaten schlüssel verfügen. aber ich denke, sie werden mir zustimmen, dass dies die messlatte höher legt. die dateisystem-acls bieten (wenn sie ordnungsgemäß implementiert sind) ein ziemlich gutes schutzniveau. und sie sind in der lage, ihre superuser persönlich zu überprüfen und zu kennen.</p><blockquote> <p>oder der schlüssel ist fest in software-binärdateien codiert, kann aber immer dekompiliert werden, und was ist mit open source-software oder interpretiertem code?</p> </blockquote><p>ja, ich habe fest codierte schlüssel in binärdateien gesehen. auch dies legt die messlatte ein wenig höher. jemand, der dieses system angreift (wenn es java ist), muss verstehen, dass java erzeugt bytecode (usw.) und versteht, wie man es dekompiliert, liest es. wenn sie eine sprache verwenden, die direkt schreibt beim maschinencode können sie sehen, dass dies die messlatte etwas höher legt. dies ist keine ideale sicherheitslösung, könnte aber ein gewisses maß an schutz bieten.</p><blockquote> <p>wenn der schlüssel generiert wird, müsste ein solcher algorithmus (vermutlich) deterministisch sein, und dann gilt das gleiche problem für den startwert.</p> </blockquote><p>ja, im wesentlichen wird der algorithmus dann zur privaten schlüsselinformation zum erstellen des privaten schlüssels. es müsste also jetzt geschützt werden.</p><p>ich denke, sie haben bei jeder sicherheitsrichtlinie ein kernproblem festgestellt: <strong> schlüsselverwaltung </strong>. die einrichtung einer schlüsselverwaltungsrichtlinie ist für die bereitstellung eines sicheren systems von zentraler bedeutung. und es ist ein <a href="http://en.wikipedia.org/wiki/key\_management">ziemlich breites thema</a> .</p><p>die frage ist also, wie sicher ihr system (und damit der private schlüssel) sein muss. wie hoch muss in ihrem system die messlatte höher gelegt werden?</p><p>wenn sie bereit sind zu zahlen, gibt es einige leute, die lösungen dafür finden. am ende haben wir ein <a href="http://en.wikipedia.org/wiki/hardware\_security\_module">hsm (hardware security module)</a> verwendet. es handelt sich im grunde genommen um einen manipulationssicheren server, der einen schlüssel in der hardware enthält. dieser schlüssel kann dann verwendet werden, um andere schlüssel zu erstellen, die für die verschlüsselung verwendet werden. die idee hier ist, dass (wenn richtig konfiguriert) der schlüssel <em> nie verlässt</em> das hsm. hsms kosten <em> viel</em>. in einigen unternehmen (z. b. beim schutz von kreditkartendaten) sind die kosten eines verstoßes jedoch viel höher. es gibt also ein gleichgewicht.</p><p>viele hsms verwenden schlüsselkarten aus der wartung und verwaltung der funktionen. ein quorum von schlüsselkarten (5 von 9, sagen wir) muss physisch in den server eingelegt werden, um einen schlüssel zu ändern. dies legt die messlatte also ziemlich hoch, indem nur dann ein verstoß zugelassen wird, wenn ein quorum von superusern zusammenarbeitet.</p><p>es gibt möglicherweise softwarelösungen, die ähnliche funktionen wie ein hsm bieten, aber ich weiß nicht, um welche es sich handelt.</p><p>ich weiß, dass dies nur einen weg zur beantwortung der frage darstellt, aber ich hoffe, dass dies hilft.</p> <p>sie versuchen, ein problem zu lösen, das sie gar nicht erst haben sollten: <strong>kennwortwiederverwendung</strong></p><p>das konzept ist einfach. sie denken an ein "gutes" passwort und verwenden dieses für alles. ihr bankkonto, online-shopping, ihr e-mail-anbieter usw.</p><p>das problem ist, wenn alle von ihnen durchgesickert sind, sind alle anderen konten möglicherweise in gefahr. <strong>dies ist ein völlig unnötiges risiko!</strong></p><h1>was ist mit meinem vorgeschlagenen schema?</h1><p>sie selbst sagten, erfinden sie das rad nicht neu. wenn sie das tatsächlich tun würden, müssten sie entweder eine anwendung schreiben, die die hashes für sie berechnet, oder sie selbst berechnen und speichern.</p><p>es gibt bereits anwendungen, die das problem der speicherung von anmeldeinformationen lösen, und sie machen es viel besser: offline-passwort-manager</p><h1>warum sind offline-passwort-manager besser?</h1><p>weil sie wirklich zufällige und eindeutige passwörter generieren. es besteht keine notwendigkeit, kryptographie in diese zu bringen. ich muss mein passwort für mein e-mail-konto nicht daran binden, dass es die zeichenfolge "gmail.com" enthält.</p><p>weil <code>sn2\zj2cw92dqx^{$omqac\_p'xr|md)[</code> ist definitiv ein besseres passwort als die md5-summe von <code>hunter2+gmail.com</code> (es ist <code>01f9a94a0febf268495d08f5960e7f05</code>, falls du dich gewundert hast).</p> <p>ich denke nicht, dass es sich um geheime oder sensible informationen handelt, z. b. "geheime informationen sind maskiert und sensible nicht". (die unterscheidung ist problematisch; viele geheimnisse müssen auch geteilt werden).</p><p>ich denke, cc- und ssn-informationen werden aus mehreren gründen nicht ausgeblendet. sie sind keine harte tatsache, aber dennoch sind hier einige:</p><ol> <li> <p>das zu tun, was alle anderen tun, überrascht den benutzer nicht. passwörter kamen lange vor webformularen und waren bereits maskiert. wenn sie in anmeldeformularen verwendet wurden, wurden sie auch maskiert. als das online-geschäft und die online-verwaltung hinzukamen, erforderte der stand der technik (papierformulare) (offensichtlich) die nicht maskierte eingabe sensibler informationen, sodass webformulare die gleiche wahl trafen.</p> </li> <li> <p>es wäre sehr einfach, einen fehler zu machen und eine falsche nummer einzugeben, wenn sie nicht sehen würden, was sie eingegeben haben. im falle eines falschen passworts ist dies nur leicht ärgerlich und sie erhalten sofortiges feedback. im fall anderer falsch sensibler daten kann dies weitere konsequenzen haben, die nicht sofort klar sind (z. b. die ablehnung einer anfrage an ein regierungsbüro aufgrund einer falschen ssn oder eine nicht durchgeführte zahlung - obwohl in den fällen cc und ssn dies wird normalerweise dadurch abgesichert, dass geprüft wird, ob die prüfsumme richtig ist, und sofortiges feedback gegeben wird, wenn dies nicht der fall ist.</p> </li> <li> <p>viele leute kennen ihre cc-nummer nicht aus dem speicher und kopieren sie von der eigentlichen kreditkarte. die nummer ist also sowieso für einen zuschauer sichtbar; das ausblenden des eingabefeldes würde nicht viel zum schutz der nummer am client-ende beitragen und verdient daher nicht die zusätzlichen schwierigkeiten, die durch 2 verursacht werden.</p> </li> <li> <p>auswirkung - eine gestohlene cc-nummer hat nicht unbedingt die gleiche auswirkung wie ein gestohlenes passwort, insbesondere wenn sie der ansicht sind, dass informationen, die durch einen blick über die schulter gestohlen wurden, höchstwahrscheinlich von personen gestohlen werden, die sie kennen (kollegen bei der arbeit, familienmitglieder, klassenkameraden) usw.) und möchten ihr passwort aus einem ganz bestimmten grund, der persönliche konsequenzen hätte. otoh, selbst wenn sie an ihrer cc-nummer interessiert wären, müssten sie den finanziellen schaden nicht in kauf nehmen, da die cc-firma ihn wahrscheinlich übernehmen würde. aus dem gleichen grund macht es ihnen nichts aus, einen kellner oder verkäufer ihre kreditkarte sehen zu lassen, obwohl er sie kopieren und an jemand anderen verkaufen könnte ...</p> </li> </ol><p>nummer 4 gilt jedoch möglicherweise nicht für andere arten von vertraulichen informationen.</p> <p>es wird in den stapel-auflösetabellen verwendet, die sie zum beispiel in der assembly-ausgabe von <a href="https://stackoverflow.com/questions/307610/how-do-exceptions-work-behind-the-scenes-in-c#307716">meine antwort auf eine andere frage</a> sehen können. wie in dieser antwort erwähnt, wird ihre verwendung durch <a href="https://itanium-cxx-abi.github.io/cxx-abi">itanium c++ abi</a> definiert, wobei sie <a href="https://itanium-cxx-abi.github.io/cxx-abi/abi-eh.html#base-personality">personality routine</a> genannt wird.</p><p>der grund, warum es "funktioniert", indem es als globaler null-leerzeiger definiert wird, ist wahrscheinlich, dass nichts eine ausnahme auslöst. wenn etwas versucht, eine ausnahme auszulösen, werden sie feststellen, dass es sich schlecht benimmt.</p><p>wenn keine ausnahmen verwendet werden, können sie diese natürlich mit <code>-fno-exceptions</code> deaktivieren (und wenn rtti nicht verwendet wird, können sie auch <code>-fno-rtti</code> hinzufügen). wenn sie sie verwenden, müssen sie (wie andere bereits erwähnte antworten) mit <code>g++</code> anstelle von <code>gcc</code> verknüpfen, wodurch <code>-lstdc++</code> für sie hinzugefügt wird.</p> <h2>ja aber..</h2><p>um es schön und klar zu machen ... wir sprechen von einem kompromiss nur für datenbanken, wenn ein angreifer zugriff auf die datenbank hat, nicht jedoch auf den quellcode der anwendung. in diesem fall erhält der angreifer die kennwort-hashes, kann sie jedoch aufgrund des benutzerdefinierten algorithmus von dave nicht knacken und die ursprünglichen kennwörter abrufen. im falle eines verstoßes nur gegen die datenbank schützt der kennwortalgorithmus von dave die kennwörter besser als bei verwendung von md5 oder sha1.</p><p><strong> dies ist jedoch </strong> nur ein möglicher weg für systemlecks. es gibt eine wichtige tatsache, die die "mathematik" zerstört, die daves homebrew-algorithmus vernünftig erscheinen lässt.</p><h2>die hälfte aller verstöße beginnt intern.</h2><p>(quellen <a href="https://www.helpnetsecurity.com/2019/06/17/human-error-data-breach/">1</a> <a href="https://www.forbes.com/sites/louiscolumbus/2018/08/31/58-of-all-healthcare-breaches-are-initiated-by-insiders/#4a6d911c601a">2</a> ) was eine sehr ernüchternde tatsache ist, wenn sie es einmal einwirken lassen. von der hälfte der von mitarbeitern verursachten verstöße, die hälfte von ihnen ist zufällig und <strong> die hälfte ist absichtlich </strong>. daves algorithmus kann hilfreich sein, wenn sie sich nur um ein nur-datenbank-leck sorgen. wenn das alles ist, worüber sie sich sorgen machen, dann ist das bedrohungsmodell, vor dem sie in ihrem kopf schützen, falsch.</p><p>um nur ein beispiel zu nennen: entwickler haben per definition zugriff auf den anwendungsquellcode. wenn ein entwickler schreibgeschützten zugriff auf die produktionsdatenbank erhält, verfügt er jetzt über alles, was er zum einfachen knacken der kennwörter benötigt. daves benutzerdefinierter algorithmus ist jetzt nutzlos, da er auf alten und leicht zu knackenden hashes basiert.</p><p>wenn dave jedoch einen modernen passwort-hashing-algorithmus verwendet und sowohl salz als auch pfeffer verwendet hätte, hätte der entwickler, der zugriff auf einen nur-datenbank-dump erhalten hat, absolut nichts nützliches.</p><p>das ist nur ein zufälliges beispiel, aber der allgemeine punkt ist einfach: es gibt viele datenlecks in der realen welt, bei denen korrektes hashing den tatsächlichen schaden gestoppt hätte, wenn daves algorithmus dies nicht konnte.</p><h2>zusammenfassend</h2><p>es geht um tiefenverteidigung. es ist einfach, eine sicherheitsmaßnahme zu erstellen, die vor einer bestimmten art von angriff schützen kann (daves algorithmus ist eine leichte verbesserung gegenüber md5 zum schutz vor nur-datenbank-lecks). dies macht ein system jedoch nicht sicher. viele reale verstöße sind ziemlich kompliziert und nutzen schwachstellen an mehreren stellen in einem system aus, um endlich echten schaden zu verursachen. jede sicherheitsmaßnahme, die mit der annahme beginnt, dass dies der einzige angriffsvektor ist, über den ich mir sorgen machen muss (was dave getan hat), wird die dinge gefährlich falsch machen.</p> <p><em>da es sich um private felder handelt, sollte es beim erstellen eines json-strings keine probleme geben.</em></p><p>ich glaube nicht, dass diese aussage zutrifft. gson prüft beim serialisieren die privaten felder des objekts, was bedeutet, dass alle privaten felder der oberklasse enthalten sind. wenn sie felder mit demselben namen haben, wird ein fehler ausgegeben.</p><p>wenn es ein bestimmtes feld gibt, das sie nicht einschließen möchten, müssen sie es mit dem schlüsselwort <code>transient</code> markieren, z.</p><pre><code>private transient bigdecimal tradefeespcy; </code></pre> <p>sicher (die anzahl der glyphen ist begrenzt, aber anscheinend verwendet ihr gebietsschema die utf-8-codierung).</p><p>ich benutze dies zum testen:</p><pre><code>#!/bin/sh # send character-string to enable utf-8 mode if test ".$1" = ".off" ; then printf '\033%%@' else printf '\033%%g' fi </code></pre><p>und (nennt es "utf8"), "utf8 on" schaltet die codierung ein.</p><p>anhand des beispiels mit <code>pstree</code> finden sie hier ein beispiel <em> nach </em> ausführen des skripts (vor der gleichen art von ausgabe wie in der frage ):</p><p> <a href="https://i.stack.imgur.com/nznw2.png">(<img src="https://i.stack.imgur.com/nznw2.png" alt="screenshot after &quot;utf8 on&quot;"></a> </p><p>wie in einem kommentar erwähnt, gibt es ein skript <code>unicode\_start</code> was <em> mehr </em> bewirkt, aber alles, was benötigt wird, um die gestellte frage zu beantworten, ist das kleine skript, das als beispiel verwendet wird.</p><p>einen anderen kommentar ansprechen: zumindest auf meinem system (und in dem in der frage gezeigten screenshot) werden alle von <code>pstree</code> verwendeten zeichen in der 512-glyphen-schriftart geliefert, die standardmäßig für die unicode-unterstützung unter linux verwendet wird konsole.</p><p>weiterführende literatur:</p><ul> <li> <a href="http://man7.org/linux/man-pages/man4/console\_codes.4.html">console\_codes - linux-konsolen-escape- und steuersequenzen</a> </li> <li> <a href="http://www.tldp.org/ldp/lg/issue91/loozzr.html">into the mist: funktionsweise von linux console-schriftarten</a> </li> </ul>