Hallo Leute!
Hier mal ein theoretisches Thema. Es geht um die Passwortverschlüsselung, die meisten von euch werden schon irgendeine Verschlüsselung gebraucht haben um irgendwelche Userpasswörter verschlüsselt zu haben. Sei es MD5, ShaXXX oder sonst was. Ich muss euch allen mitteilen die ihre Passwörter speichern, dass sie es gleich auf Plaintext umstellen können.
Entwickler vs. Angreifer
Der ewige Kampf der Entwickler ihre Systeme abzusichern vor Angreifern, die wider rum versuchen deren Systeme zu Hacken. Kein System ist sicher und wird später oder früher gehackt. Sei es euer unbedeutendes UCP oder das PSN. Wir Entwickler müssen aber die wichtigsten Daten sichern, vor allem die Passwörter der User. Wir als Entwickler müssen bei der Verschlüsselung der Passwörter dem Angreifer keine Vorteile zulassen. Verschlüsselungen werden immer älter doch die Computerhardware erneuert sich von Jahr zu Jahr, somit sollten wir eine Verschlüsselung haben die sich Jahr zu Jahr verbessern. Momentane Verschlüsselungen wie z.B. Sha256 brauchen CPU Power. Der Angreifer kann aber mit der gleichen Hardware nur halt mit der GPU Millionen solcher Passwörter in Sekunden generieren und somit das Passwort(abhängig der Komplexität) in Stunden, Tage, Wochen, Monaten brutforcen. Das einzige Mittel dagegen ist den Usern zu sagen, dass Sie große Komplexe Passwörter verwenden sollten(und verschiedene), das machen wir schon seit 20 Jahren, und trotzdem hilft es nichts.
Die Lösung?
Die Lösung liegt sehr nahe, man darf den Angreifer keinen Vorteil einräumen. Er soll mit der gleichen Hardware die gleichen Bedienungen haben. Und ich als Entwickler soll die Möglichkeit haben, CodeTechnisch Hardwareupgrades leicht entgegenzuwirken. Deshalb lege ich jedem Entwickler der mit solchen Sachen zu tun hat Scrypt ans Herz.
Scrypt? Kann man das essen?
Scrypt wurde genau wegen solchen Brutforce Attacken entwickelt, man will dem Angreifer den großen Vorteil wegnehmen. Scrypt hashed das Passwort immer wieder(so oft man will) man muss dann den Wert immer wieder Cachen, der schnellste Speicher für dies ist der RAM, für jeden weiteren Durchgang brauchen wir also RAM.
PseudoCode: Hash(Hash(Hash(Hash(Hash(STRING))))). Der Angreifer hat mit der gleichen Hardware also keine Chance einen Vorteil rauszuholen. ECC-RAM würde ich dabei empfehlen 
Quellen: http://www.tarsnap.com/scrypt.html
Ich habe hier(http://bitcoin.stackexchange.c…ke-tenebrix-gpu-resistant) noch eine tolle Beschreibung gefunden:
ZitatAlles anzeigen
The scrypt() algorithm has at its core a routine called ROMmix. Basically, it defines
V(1) = hash(message)
V(2) = hash(hash(message))
V(3) = hash(hash(hash(message)))
...
and it calculates
V(V(V(V(...(message))))
Since computing V(n+1) requires computing V(n) first, the most efficient way to do this is to cache all of the previously-computed values. Once you've generated a large enough table, the V(V(V(...))) is just a bunch of lookups.
Caching all the previously computed values requires lots of memory, and since each lookup depends on the previous one it's sensitive to memory latency (although if you're mining you can work on several blocks in parallel and pipeline the requests to get around this).
GPUs can perform far more integer operations per second than a normal CPU, but have roughly the same memory bandwidth/latency as a CPU. So an algorithm that is memory-dominated should "level the playing field" between CPUs and GPUs.
I still don't understand why the Tenebrix folks consider this to be an important goal. It just "equalizes" GPUs and CPUs, but you can still build custom hardware that does scrypt() much faster and cheaper than a CPU. So it's just going from "GPUs are best" to "custom printed circuit boards covered in memory buses are best". Nobody's been able to explain why this change is worth all the trouble.
Für Entwickler hier noch eine tolle GoLang Lib: http://godoc.org/github.com/gebi/scryptauth
PS: Salten auch nicht vergessen
