Aber man kann doch hoffentlich mit c++ entschlüsseln, was php, perl, java(jsp) verwurschtelt hat und andersrum. Oder nicht?
Passwörter sicher abspeichern
-
-
Es geht ja gerade darum die Passwörter so zu verschlüsseln, dass sie nicht entschlüsselt werden können. Wozu sollte man das machen wollen?
-
Ich habe RSA gemeint - wenn man nachrichten sicher verschlüsseln kann, muss man sie doch wieder herausfinden können, ansonsten hätte RSA ja keinen sinn, könnte man gleich bei MD5 bleiben. Es geht mir um sowas z.B.:
Onlineoffice mit zugriff per browser und z.B extra programm (c++) oder mobilen geräten (objective c/java) -
Ja er will den Privaten Schlüssel mit dem verschlüsselt worden ist ja gleich löschen...
Abgesehen davon gehts hier um keine Texte die verschlüsselt werden sollen und wieder entschlüsselt
md5 kannst du nicht entschlüsseln 1. Wurde da nie was verschlüsselt 2. kannst du es nur abgleichen wie oft noch
Und um was geht es dir?
mfg
-
Hab ich doch gesagt RSA. Wenn ich einen text mit php verschlüssle und abspeichere, kann ich dann, natürlich durch übertragung von D diesen text mit c++ entschlüsseln kder andersrum. Das man md5 nicht entschlüsseln kann weiss ich, soll man ja auch nicht können.
-
Hab ich doch gesagt RSA. Wenn ich einen text mit php verschlüssle und abspeichere, kann ich dann, natürlich durch übertragung von D diesen text mit c++ entschlüsseln kder andersrum. Das man md5 nicht entschlüsseln kann weiss ich, soll man ja auch nicht können.
D wird NIEMALS übertragen.
Du generierst im Normalfall verschiedene Schlüssel auf beiden Seiten.
Der öffentliche Schlüssel wird ausgetauscht. Damit wird verschlüsselt. Und der private Schlüssel entschlüsselt das wieder. -
??? Jetzt check ichs nichtmehr, wie soll denn dann die gegenseite den text wieder entschlüsseln? Wenn ich jetzt dodo einen mit rsa verschlüsselten text senden will, dann beaucht er doch D um zu wissen, was ich sagen will, oder nicht?
-
Richtig D muss er haben, der ist aber immer gleich von dem her muss er auch nicht mitgeschickt werden
-
Danke, ich dachte D hängt immer von N E und dem text ab, dann wärs ja unmöglich. Aber kann man nun unter verwendung von D texte sprachenunabhängig ver-/ent- schlüsseln? Wenn die schlüssel (laut dodo) so verschieden sind, ist mit das fragwürdig.
-
Danke, ich dachte D hängt immer von N E und dem text ab, dann wärs ja unmöglich. Aber kann man nun unter verwendung von D texte sprachenunabhängig ver-/ent- schlüsseln? Wenn die schlüssel (laut dodo) so verschieden sind, ist mit das fragwürdig.
RSA basiert auf Mathematik. Mathematik funktioniert immer gleich.
Das ist ein theoretischer Algorithmus, der mit ziemlich jeder Sprache nachprogrammiert werden kann.
Du kannst RSA - mit kleinen Schlüsseln - mit Stift und Papier nachrechnen.
Das hier ist nur eine Implementierung in PHP. In PHP geht das dank der BC Math Library recht einfach. Es entstehen unter Umständen Schlüssel > 100 Bit. Mit PHP kann man das schön berechnen. Bei anderen Sprachen benötigt man entsprechende Funktionen, da es kaum so große Variablen gibt.
Aber die eigentliche Funktion von RSA - das Modulo-Potenzieren - kann in jeder Sprache realisiert werden.Wenn du Nachrichten per RSA sichern willst: Angenommen, du willst mir eine Nachricht schicken:
Ich berechne N und E. Daraus ergibt sich D.
Ich stelle nun N und E öffentlich zur Verfügung. Jeder, der mir eine Nachricht schicken will, verschlüsselt sie mit N und E. Aber nur N und D können diese Nachricht wieder entschlüsseln. Da nur ich D kenne - und das auch immer so bleiben sollte - bin ich der Einzige, der das rückrechnen kann. -
Jetzt habs sogar ich verstanden danke!
-
Ich habe mich mit den verschiedenen Verschlüsselungsverfahren noch nicht so sehr beschäftigt, muss ich zugeben.
Meines Wissens ist MD5 nicht entschlüsselbar, es gibt lediglich die sogenannten Rainbow-Tables zum Abgleich.
Daher ist ein reines $pass = md5($pass); natürlich längst nicht mehr ausreichend.
Aber unter der Annahme, dass md5 nicht entschlüsselbar ist, sondern eben lediglich auf rainbow-tables beim Knacken zurückgegriffen wird, was ist dann an folgender Verschlüsselung unsicher:
MD5_SALT ist eine Konstante die man in einer config-Datei ablegt.
$salt ist ein md5-Hash aus uniqid('',true) der zum einen vor dem hashen, gemeinsam mit dem konstanten MD5_SALT, an das eigentlich Passwort gehängt wird, und danach nochmal an den Hashwert um diesen Salt beim PW-Check zur Verfügung zu haben. Da dürften doch eigentlich keine Rainbow-Tables mehr greifen?Das RSA-Verfahren werde ich mir aber bei Gelegenheit mal anschauen, das sichere Verschlüsseln mit der Option einer Entschlüsselung könnte ich grad gut brauchen, für einen online-Passwortmanager den ich gerade nebenbei entwickle um überall immer Zugriff auf alle meine Passwörter für diverse Seiten, eMails etc. zu haben. Die möchte ich ungern im Klartext in meiner DB ablegen
-
Das Problem bei Hashs ist, dass bereits eine Kollision ausreicht, um sich bei Logins mit gehashten Passwörtern Zutritt zu verschaffen. Da hilft nicht einmal ein Salt.
Diese Kollisionen sind bei RSA absolut unmöglich.Zu deiner Anwendung: Für kurze Texte ist RSA bestens geeignet. Bei längeren Texten würde ich aufgrund der Performance auf symmterische Verfahren, wie zum Beispiel AES (Advanced Encryption Standard - Rijndael) zurückgreifen.
Oder hybride Verfahren, in denen der Schlüssel für ein symmetrisches Verfahren mit RSA verschlüsselt ist. -
Ein Kollision zu finden ist extrem, extrem, extrem gering, vorallem bei Hashfunktionen mit mehr Bits wobei md5 ja ausreicht.
Außerdem hast du mit einer Kollision Zugriff, aber noch lange kein Passwort.
-
Ich mach das eigentich ganz einfach.
Mit den Rainbow-Tables ist es möglich, schon viele Passwörter nachzuschauen.Daher mach ich das:
Einfach zuerst das Passwort mit md5() verschlüsseln und dann nochmal mit sha1() oder nochmal md5() oder umgekehrt.
Somit kann man das so gut wie nicht nachschlagen und man ist eigentlich auf der sicheren Seite.Meiner Meinung nach ausreichend, oder sieht da wer ein Problem darin?
-
Du kannst es auch 10000 mal in md5 oder sha1 packen, das Ergebniss bleibt das selbe, ich würde einen Salt nehmen schon allein weil ich dann unabhängig von der jeweiligen Hashmethode bin
'$password'.'$regTime'
Einfach zb die Registrierungszeit an das Password hängen (wenn du willst auch ruhig weng durchmischen)
-
Ja, aber was bringt mir ein Salt im Endeffekt?
Ich seh keinen grossen Sinn dahinter, Salt zu verwenden, wenn für mich schon zweimal MD5 oder SHA1 und MD5 gut genug aussieht.Aber ehrlich gesagt ist auch schon MD5 allein genügend, denn, an die MD5 Hashs ranzukommen muss man den Datenbankzugang "hacken" und erst dann hat man die Hashs, ausser man proggt natürlich einen Quatsch zusammen und gibt Fehlermeldungen in reinem Text des myql_error() aus.
-
Ich würde die Frage andersrum stellen, warum Hash du nen Hash wenn es reicht einfach einen String an das Password dranzuhängen und das auch sicherer ist?
Wenn ich deine Datenbank habe und das Script zb (falls ich das auch hätte) sehen würde das du 2mal hashed (oder das anhand das Forums weis:P), würde ich einfach die Rainbowtable daraufhin ändern und eben dort die "doppelten/mit sha1 md5 hashes" reinspeichern/ändern.
Wenn du aber einen Userbezogenen Salt hast dann wäre der Salt ja pro User anders von dem her bräuchtest du erst den Salt und der kann zb auf einen anderen Server liegen.. Und selbst dann musst du pro User deine Rainbowtables ändern
Abgesehen davon das wenn der Angreifer Zugriff aufs Filesystem hat schon ziemlich alles verloren ist
EDIT:
Ach gott der versteh ja keine Sau mein geschreibsel:D
Ich wollte eigentlich nur sagen das man nen Salt nicht einfach so aufschnappen, erraten kann, vorallem einen Userbezogenen und das man dann pro User eine extra Regentabelle braucht.mfg
-
Regenbogentabellen, hmm...
Keine Angst, ich versteh dein Geschreibsel schon.Zum Thema:
Okay, das ist ein festes Argument.
Aber wie willst du das bewerkstelligen, dass du, falls du gehackt wirst (was eher unwahrscheinlich ist), den Salt nicht auch gleich dem Hacker übergibst?
Wie willst du das machen, dass der Salt auf einem anderen Server liegt und der dann auch nicht noch gehackt wird?
Denn der Server stünde sicher auch drin und dann hätte er auch Zugang zum Server oder wie meinst du das??Ach schau vielleicht mal das hier an: http://www.phpbuddy.eu/
Da steht auch noch was zur Sicherheit und PHP, sehr interessant, finde ich. -
Hier ist ein weiterer Vorteil an der RSA-Verschlüsselung.
Wenn der Hacker alles über das verwendete Verfahren weiß:
*) Hash: Salt, Verschachtelung, etc.
*) RSA: Den öffentlichen Schlüssel
...dann ändert sich an der Sicherheit vom verschlüsselten nichts. Von der Sicherheit des Hashs ändert sich einiges - wie ihr gerade so sagt: Rainbow-Tables -