T-SQL: Gesalzene Passwörter

Ich bin auf der Suche nach ein Beispiel von Salzen der Passwörter innerhalb eines T-SQL-Gespeicherte Prozedur. Und natürlich die passenden proc-zum überprüfen eines Benutzers.

CREATE PROC ChangePassword(@Benutzername vom Datentyp nVarChar(50), @Passwort nVarChar(50))

CREATE PROC ValidateUser(@Benutzername vom Datentyp nVarChar(50), @Passwort nVarChar(50))

InformationsquelleAutor Jonathan Allen | 2011-05-12

passwords tsql

15

Erste, ich werde gehen auf ein Glied hier und sagen, dass hashing der Passwörter in der Datenbank ist in der Regel eine schlechte Praxis im Hinblick auf Sicherheit. Sie würden nicht geschützt werden gegen-traffic-Sniffer beobachten den Verkehr auf der Datenbank. Der einzige Weg, um gegen zu schützen, ist, um sicherzustellen, dass Ihre Verbindung zu der Datenbank war verschlüsselt, was in der Regel bedeutet, dass alle anderen traffic auf der Datenbank werden verschlüsselt. Es ist möglich, dies zu umgehen, aber die bessere Lösung ist, um die Anwendung(en) tun das hashing.

Als Sam Safran angegeben, können Sie die Hashbytes Funktionen, um SHA1-hashing. Wenn Sie wollen eine bessere algorithmen müssten Sie zum erstellen einer CLR-Prozedur. Salzen würde die Speicherung einer kryptografisch zufälligen Wert für jeden Benutzer, dann anfügen, dass der Wert das Passwort ein und es läuft durch Hashbytes:
```
Create Procedure ValidateUser
    @Username nvarchar(50)
    , @Password nvarchar(50)
As

Declare @PasswordSalt varbinary(256)

Set @PasswordSalt = ( Select PasswordSalt From Users Where Username = @Username )

If @PasswordSalt Is Null
        -- generate a salt? 

Declare @Hash varbinary(max)
Set @Hash = Hashbytes('SHA1', @PasswordSalt + Cast('|' As binary(1)) + Cast(@Password As varbinary(100))

If Exists(  Select 1
            From Users
            Where Username = @Username
                And PasswordHash = @Hash )
    -- user is valid

Else
    -- user is not valid
```
Denken Sie daran, dass das Salz sollte kryptographisch zufällig, so würde ich nicht empfehlen die Verwendung der NewId(). Stattdessen möchte ich generieren, die mit so etwas wie .NET die RNGCryptoServiceProvider-Klasse.
- Thomas, ich dachte, der Grund für das Salz, die Niederlage war, die rainbow-Tabellen. Was ist die rationale für die macht es kryptographisch sicher?
- Safran - Nicht so viel kryptographisch sicher als kryptographisch random. Die Zufälligkeit reduziert clustering von salt-Werten.
- sorry meine nicht ein Schmerz hier, was bedeutet clustering das Salz haben?
- Safran - Es erhöht die Verschiedenheit der Ableitung der Salze. Zugegeben, einen Unterschied zu machen, wir reden über eine hartnäckige hacker und viel von Passwörtern gegeben und wir reden über die potentielle Sicherheitslücke zu senden das pwd in Klartext in die db zu hash, mit NewId() würde wahrscheinlich gut genug sein. Im Allgemeinen bin ich nicht davon ausgehen, dass NewId() ist wirklich zufällig, aber in diesem Fall, Sie können es als zufällig genug.
- Ich sehe kein problem mit, dass Sie eine Verbindungszeichenfolge für den sicheren Betrieb und eine zweite für die bulk-Daten übertragen. Plus dieses mal, mir die Geheimnisse aus dem web-Server.
- Allen -, Wenn Sie Hash-Passwörter, es gibt keine Geheimnisse auf dem Webserver. Der hash-Algorithmus wird nicht als ein Geheimnis. RE: Verbindungen. Ich bin mir auch nicht sicher, dass Sie sagen können, SQL-Server verschlüsselt den Datenverkehr und andere nicht. AFAIK, es ist alles oder nichts.
- Verdammt, du hast Recht. Ich war wirklich erwartet, in der Lage zu Steuern, ob oder nicht, ich bin mit SSL auf einer pro-Verbindung-basis, aber es ist wirklich alles oder nichts. technet.microsoft.com/en-us/library/ms177485.aspx
InformationsquelleAutor Thomas
2

Können Sie HASHBYTES, um SHA1-ein string, und NEWID() zu generieren, die eine zufällige Guid als Salz.
- Das heißt, in der Regel ziehe ich BCrypt in diesen Tagen, es gibt viel über Sie, auf SO hier: stackoverflow.com/questions/1561174/... und stackoverflow.com/questions/3722780/...
- Obwohl ich nicht glaube, Sie tun können, bcrypt in T-SQL (nicht, dass Ihr Sicherheitscode Leben sollten, die in T-SQL wie auch immer...)
- Ich bin mir auch ziemlich sicher, dass newid ist nicht kryptographisch stark. Weder mit MD5 oder SHA1, aber alles in Grad...
- stimmt, das scheint der falsche Ort für diesen code könnte man bcrypt mit sql clr coldfusion.tcs.de/... oder einen längeren proc, aber eigentlich ist dies der falsche Ort
- stark genug, um gegen eine rainbow-table 🙂 und ärger mit und gesalzener sha1-Hash ist, dass man brute-force-it.
- Safran - Würde es nicht tun, Ihre Hash in die db (ob per T-SQL oder CLR) verlangen, dass Sie zum verschlüsseln der Kommunikation auf die db um zu verhindern, dass das schnüffeln des Verkehrs?
- sicher, aber das gleiche gilt für alles sensible, den Sie speichern in der db un-verschlüsselt. Ich persönlich würde nicht diese Art von code auf meinem db-server es fühlt sich wie seine in der falschen Stelle
- Safran - Wenn Sie hash das Passwort des Benutzers auf dem web-server, die einzige Sache, die gespeichert in der db den hash (und die unverschlüsselte Salz). Also, wenn jemand Stiehlt die db, Sie haben nur die hashes und Salze. Allerdings, wenn Sie den Hash in eine gespeicherte Prozedur, die Sie haben zu senden Sie das Kennwort im Klartext in die db zu hash. Dass der Verkehr können leicht entdeckt werden (z.B. SQL-Profiler). Die pwd geschützt ist, in die db aufgrund der Tatsache, Hash. Doch der Verkehr auf der db ist (standardmäßig) nicht geschützt.
- Ich kann Total akzeptieren, dass das hashing von Passwörtern auf die db ist eine Dose Würmer lohnt sich nicht öffnen
InformationsquelleAutor Sam Saffron
1

haben Sie sich überlegt Salzen passswords auf Anwendungsebene.die server-hardware zur app-Server esp. Cpu könnte gewesen mehr geeignet als der dbmss zu verarbeiten, hashing und salting?
- Dies war vor allem Neugier. Das heißt, dies ermöglicht mehrere Anwendungen ohne die Notwendigkeit, zu bauen, eine Art von Middleware.
InformationsquelleAutor Oh Chin Boon

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.