gemeinsam zwiften | youtube | forum heute
4 Radtage Südbaden
4 Radtage Südbaden
Keine Flugreise
Deutschlands wärmste Gegend
Kilometer sammeln vor den Wettkämpfen
Traumhafte Trainingsstrecken
Training auf dem eigenen Rad
09.-12.05.2024
EUR 199,-
triathlon-szene.de | Europas aktivstes Triathlon Forum - Einzelnen Beitrag anzeigen - https für triathlon-szene
Einzelnen Beitrag anzeigen
Alt 10.11.2016, 17:21   #44
deralexxx
Szenekenner
 
Registriert seit: 29.10.2012
Beiträge: 1.867
Zitat:
Zitat von Thorsten Beitrag anzeigen
Ich habe es mal ergänzt .

Wenn du es im Client salzt, müsstest du aber zumindest auch den Salt im Client und damit sichtbar halten. Würde aber zumindest den Gebrauch von Rainbow tables nutzlos machen, oder?
Richtig, Rainbow Tables werden dadurch deutlich erschwert (unmöglich ist es nicht, geht dann aber in Richtung unendlich aufwändig in Bezug auf Zeit und oder Rechenleistung)

https://crackstation.net/hashing-security.htm:

Zitat:
In a Web Application, always hash on the server!

If you are writing a web application, you might wonder where to hash. Should the password be hashed in the user's browser with JavaScript, or should it be sent to the server "in the clear" and hashed there?

Even if you are hashing the user's passwords in JavaScript, you still have to hash the hashes on the server. Consider a website that hashes users' passwords in the user's browser without hashing the hashes on the server. To authenticate a user, this website will accept a hash from the browser and check if that hash exactly matches the one in the database. This seems more secure than just hashing on the server, since the users' passwords are never sent to the server, but it's not.

The problem is that the client-side hash logically becomes the user's password.
All the user needs to do to authenticate is tell the server the hash of their password. If a bad guy got a user's hash they could use it to authenticate to the server, without knowing the user's password! So, if the bad guy somehow steals the database of hashes from this hypothetical website, they'll have immediate access to everyone's accounts without having to guess any passwords.

This isn't to say that you shouldn't hash in the browser, but if you do, you absolutely have to hash on the server too. Hashing in the browser is certainly a good idea, but consider the following points for your implementation:
...
(unterstrichen durch mich)

Wobei das Salting normal durch die Board Software geschehen sollte.
Was man mit einem Auszug an (auch gesalzenen) Hashes machen kann (die in dem Fall von der gleichen Software wie auf TS stammen) anstellen kann:

https://www.troyhunt.com/data-breach...etin-and-weak/

A
deralexxx ist offline   Mit Zitat antworten