Wat je echt doet, is hashen: je hebt een hash-functie gebouwd uit een blokcijfer. Overigens is "versleuteling van een bekende waarde met het wachtwoord als sleutel" de manier waarop het traditionele DES-gebaseerde cryptoschema voor Unix is ontworpen.

Aan de positieve kant omvat uw constructie de gebruikersnaam, die gedeeltelijk het effect van een salt: parallel kraken geeft, wordt afgeraden omdat twee gebruikers die hetzelfde wachtwoord gebruiken, uiteindelijk twee verschillende hash-outputs krijgen. "Gedeeltelijk", omdat bij het wijzigen van het wachtwoord de gebruiker zijn gebruikersnaam behoudt, dus een vorm van parallellisme is hier nog steeds mogelijk; en misschien nog belangrijker is dat dezelfde gebruikersnaam kan worden gebruikt in verschillende webapps (bijv. 'admin'), waardoor vooraf berekende tabellen de moeite waard zijn (en het punt van zout is om parallellisme te voorkomen, met name het efficiënte gebruik van vooraf berekende tabellen).

Aan de minkant:

• Dit is een zelfgemaakte constructie. 50 jaar onderzoek in cryptografie hebben ons geleerd dat zelfgemaakte crypto zeer zelden goed is. In feite kunnen we "weten" dat een bepaald algoritme alleen correct is door jarenlange beoordeling door andere bekwame onderzoekers, en zelfgemaakte schema's hebben per definitie nooit veel aandacht gekregen.

• Dit is beperkt. Rijndael is een blokcijfer dat sleutels tot 256 bits kan accepteren; dus als u het wachtwoord als sleutel gebruikt, moet het binnen 256 bits passen. Dit voorkomt het gebruik van zogenaamde "wachtzinnen" die sterk kunnen zijn, maar gemakkelijk te onthouden wachtwoorden door veel ruimte te gebruiken voor de entropie ervan (menselijke hersenen houden niet van geconcentreerde entropie, maar zijn blij met verdunde entropie).

• Dit gaat veel te snel, en dit is het grootste directe probleem in uw schema. Met een standaard-pc kan een aanvaller veel wachtwoorden per seconde proberen, vooral omdat moderne pc's speciale opcodes voor AES hebben. Met een quad-core pc zou je ongeveer een half miljard moeten kunnen proberen wachtwoorden per seconde . Er zijn niet veel door de gebruiker gekozen wachtwoorden die een dergelijke aanval lang kunnen overleven.

Als je geïnteresseerd bent in hoe wachtwoordhashing werkt, lees dan dit. Het korte antwoord is echter nog steeds hetzelfde: gebruik geen zelfgemaakt schema; gebruik bcrypt.

De andere antwoorden zeggen al Nee, "rol je eigen" is zelden een goed wachtwoordopslagschema en die van jou is geen uitzondering.

Ik zou graag willen toevoegen: is ook geen goed schema voor het opslaan / communiceren van de gebruikersnaam.
Je bent eigenlijk aan het hashen. Daar is niets mis mee, behalve:

• Je gebruikt een functie die niet ontworpen is als een veilige hashfunctie. Omdat het een cijfer is, is het zeker aan het "veilige" einde van de schaal, maar hashing houdt ook in dat hash-botsingen worden vermeden. Een cijfer is doorgaans niet geoptimaliseerd om geen botsing te hebben. One-Time Pads staan ​​erom bekend dat ze onbreekbaar zijn, omdat ze het maximale aantal botsingen hebben. Dus een sterk cijfer maakt een slechte hash in termen van botsingen.
• Als je gebruikersnaam en gebruikersnaam-versleuteld-met-wachtwoord opslaat, zijn er meer kwetsbaarheden:
  • In dit geval, als je database wordt gehackt, krijgt de aanvaller niet alleen de gebruikersnaam versleuteld met een onbekend wachtwoord . Hij krijgt ook de duidelijke tekst aka. gebruikersnaam. Het is dus een duidelijke tekstanalyse, die voor sommige cijfers veel gemakkelijker is dan brute kracht.
  • Hash-botsingen: de aanvaller hoeft het wachtwoord niet te weten, maar alle die dezelfde codering produceert voor een korte en duidelijke tekst. Dit is misschien zelfs eenvoudiger dan analyse in zuivere tekst.
• Als u de gebruikersnaam niet opslaat maar vertrouwt op één gecombineerde verzonden waarde, zijn er nog steeds nadelen:
  • In dit geval heb je waarschijnlijk geen rekening gehouden met hash-botsingen. Hoe zit het met twee gebruikers die dezelfde gebruikersnaam hebben? Hoe zit het met twee idioten, die dezelfde gebruikersnaam en hetzelfde wachtwoord hebben? Hoe zit het met hash-botsingen van verschillende gebruikersnamen en wachtwoorden door puur toeval (onthoud: cijfers zijn niet geoptimaliseerd om botsingen te voorkomen!)?
• In elk geval is er de "Pass the hash" -aanval: een aanvaller die netwerkcommunicatie snuffelt, kan eenvoudig uw applicatie emuleren om dezelfde gegevens door te geven als de gebruiker. Heb je daar iets aan gedaan? Als dat niet het geval is, moet u daarom niet "uw eigen rol spelen".

Vaak is het overdrachtsprotocol net zo belangrijk voor de beveiliging als een sterke cryptografische functie, onafhankelijk van hashing of versleuteling. Een slecht protocol kan uw functie blootstellen aan aanvallen waarvoor het niet geschikt is, met name "side channel-aanvallen" zoals "pass the hash" of "man in the middle" die de daadwerkelijke crypto-analyse aan de kant van de aanvaller omzeilen.

Uw wachtwoordopslagschema kan vatbaar zijn voor dergelijke aanvallen, omdat u niet hebt aangegeven of de gebruikersnaam ook in gewone tekst wordt opgeslagen. Hierdoor wordt uw plan blootgesteld aan de hierboven beschreven aanvallen. Als u het niet in gewone tekst opslaat, kan een overdrachtsprotocol nodig zijn dat vatbaar is voor aanvallen, zoals hierboven beschreven.

Hier zijn enkele aanvullende gedachten over overdrachtsprotocollen in uw geval, enigszins algemeen:

Als u dat niet deed doe niets aan de "pass the hash" -aanval, dan is je plan erger dan die van heel veel andere. Een aanvaller hoeft uw database niet te hacken of uw cijfer te kraken. Hij krijgt gratis wat hij nodig heeft door netwerkverkeer te snuiven.

HTTPS kan volstaan, hoewel het kan worden omzeild door "man in the middle": gebruikers controleren niet op authenticatiecertificaten, toch? Een aanvaller opent eenvoudig een niet-geverifieerde maar gecodeerde verbinding met uw gebruiker en wat er ook maar naar u wordt verwacht.

Een extra Challenge-Response-schema kan de beveiliging toevoegen. Voorafgaand aan het inloggen ontvangt de client een eenmalige willekeurige string (challenge) die hij in de hash (response) moet inbouwen. Een aanvaller kan een gesnoven hash niet opnieuw gebruiken, omdat de uitdaging ook niet opnieuw wordt gebruikt.
Maar nogmaals, het is niet nodig om je eigen hash te rollen.

TL; DR: gebruik scrypt. Waarom zelf rollen als er een prima standaard is?

(Ik beschouw scrypt als superieur aan bcrypt, maar bcrypt is nog steeds mijlenver beter dan zelf kweken.)

Eén ding tot nu toe ontbreekt het zich uitrekken. Stel je voor dat je wordt gehackt en dat je database in pastebin wordt gedumpt - het kan de besten van ons overkomen.

De mensen die 123456 of een van de andere top 20 wachtwoorden gebruiken, krijgen ontdekte wat je ook doet, en ze verdienen niet beter. Voor de mensen die redelijk goede wachtwoorden hebben gekozen, maakt het verschil of de tijd die de aanvaller per item moet besteden in de orde van microseconden of seconden is.

Je bent ook niet aan het zouten - stel je voor dat twee van uw webapplicaties worden gehackt en één persoon heeft accounts onder dezelfde gebruikersnaam met hetzelfde wachtwoord voor beide. Het klinkt voor mij alsof de aanvaller identieke cijferteksten krijgt in beide stortplaatsen, om hen te vertellen dat er een crack-one-get-one-free aanbieding is.