Het kernprobleem: als uw server efficiënt een gehasht wachtwoord kan vergelijken met (mogelijk) alle de gehashte wachtwoorden voor de hele gebruiker, dan kan een aanvaller dat ook. Een aanvaller die een kopie van uw serverbestanden / database bemachtigt, kan een offline woordenboekaanval uitvoeren, dwz het potentiële wachtwoord hashen en zoeken naar een overeenkomst.

Bij normale wachtwoordhashing wordt een salt per wachtwoord gebruikt om voorkomen parallelle aanvallen: we willen dat de aanvaller de volledige rekenprijs van de hash-functie betaalt (die door vele iteraties duur wordt gemaakt) voor elk wachtwoord en elk gebruikersaccount. Als verschillende wachtwoord-hashes echter hetzelfde salt gebruiken, kan de aanvaller een potentieel wachtwoord proberen tegen allemaal voor de kosten van één aanroep van een hash-functie. Dus uw "globale zout" verzwakt het schema aanzienlijk: het stelt de aanvaller in staat om 1000 accounts aan te vallen voor de kosten van een aanval.

Het belangrijke punt: uw probleem is er een van tijdelijkheid. In feite wil je een nieuw gebruikerswachtwoord niet vergelijken met alle wachtwoorden van alle andere gebruikers; wat u wilt, is het wachtwoord dat door elke gebruiker is gekozen tijdens de registratie, vergelijken met een beperkte lijst van "wachtwoorden van bekende overtreders". Wanneer een geregistreerde gebruiker de status "overtreder" krijgt, is hij helaas al geregistreerd en is zijn wachtwoord niet bewaard gebleven, alleen de hash ervan. U wilt dus echt toegang hebben tot het wachtwoord dat is gebruikt voor de registratie nadat de registratie heeft plaatsgevonden.

Een mogelijke oplossing: gebruik escrowing, ook bekend als asymmetrische versleuteling. Maak een RSA-sleutelpaar. Bewaar de openbare sleutel op de server. Bewaar de bijbehorende privésleutel NIET op de server; bewaar het in plaats daarvan ergens anders, bijv. op een laptop die offline wordt bewaard (of misschien slechts op een paar USB-sticks).

Wanneer een gebruiker zich registreert, hasht hij zijn wachtwoord zoals gewoonlijk (met PBKDF2, veel iteraties, een nieuwe willekeurige salt, enz.). Maar codeer het wachtwoord (niet de hash) met de RSA-sleutel, en sla het coderingsresultaat op in uw database, samen met de hash. Versleuteling heeft alleen de openbare sleutel nodig en is willekeurig, dus deze versleutelde versie geeft geen extra invloed aan een aanvaller die een kopie van de database-inhoud krijgt. Wanneer een gebruiker inlogt, wordt de wachtwoordhash gebruikt, zoals gewoonlijk.

Wanneer een gebruiker een spammer blijkt te zijn, haalt u de privésleutel op en decodeert u het geblokkeerde wachtwoord. Op die manier verkrijgt u het "slechte wachtwoord" en kunt u dit toevoegen aan de lijst met wachtwoorden die u bij registratie wilt weigeren. Die lijst kan als duidelijke tekst worden bewaard: aangezien de bijbehorende rekeningen zijn gesloten, is daar geen probleem mee. Zorg ervoor dat u de decodering uitvoert op een "veilige" machine, bij voorkeur offline: u wilt echt niet dat die privésleutel wordt gestolen.

Een waarschuwing: spammers zijn als bacteriën, in dat ze de neiging hebben om te evolueren met betrekking tot externe beperkingen. Als je spammers eruit filtert op basis van hun gewoonte om wachtwoorden te hergebruiken voor registratie, zul je ze snel leren om willekeurige wachtwoorden te genereren. Daarom voorspel ik dat als je zo'n systeem installeert, het na relatief korte tijd niet meer effectief zal zijn om spammers eruit te schoppen; daarna is het gewoon dood gewicht in uw database (niet veel, want een RSA-gecodeerd kort bericht met een 2048-bits RSA-sleutel is slechts 256 bytes, maar niettemin dood gewicht).

Dat kan niet. Het maakt de zekerheid van het hebben van een uniek zout (of welk zout dan ook) volledig ongedaan. Het punt van een uniek zout is dat het het gebruik van een regenboogtafel voorkomt om het wachtwoord te identificeren. Door op te slaan met een globale salt kan die tafel worden aangevallen met een regenboogtafel en hoogstwaarschijnlijk in veel gevallen het originele wachtwoord identificeren.

Het alternatief hiervoor is om een ​​lijst met salts te genereren om een ​​nieuw wachtwoord tegen te proberen. (degene die zijn gekoppeld aan eerdere spammers). Het maakt het aanmaken van een nieuwe gebruiker een iets moeilijkere bewerking, aangezien je de wachtwoordhash meerdere keren moet uitvoeren, maar het is de enige veilige manier om te doen waar je het over hebt. Het maken van nieuwe gebruikers zou ook de enige keer moeten zijn dat u deze stap moet uitvoeren, dus het zou niet een te grote hit moeten zijn. Ik zou het ook alleen aanraden als andere indicatoren lijken te ondersteunen dat het een spamgebruiker is, als je de impact verder wilt verminderen.

Je kunt ook slechte wachtwoorden opslaan nadat ze zijn geïdentificeerd om de lijst kort te houden . De vorige gebruiker met salt 1234 had bijvoorbeeld een hash abcd. Wanneer een nieuwe gebruiker het wachtwoord "ImSpam" indient en u het probeert tegen salt 1234, ziet u dat het abcd is en nu het daadwerkelijke wachtwoord voor dat salt kent, dus u kunt stoppen met het controleren en het wachtwoord alleen volledig weigeren. Dit zou de lijst relatief kort moeten houden. Je kunt ook oude spamgebruikers mogelijk laten verouderen, want als je al een tijdje niet bent aangevallen door die spammer, is de kans groot dat ze het opgaven.

Laten we de uniek gezouten hashes "beter" noemen en de globale / enkelvoudig gezouten hashes "slechter". Om prestatieredenen wilt u misschien de betere hashes in de gebruikersdatabase behouden, zodat u gebruikers snel kunt verifiëren. Ik raad aan om de "slechtere" hashes naar een andere, meer beveiligde server te verplaatsen met een dunne, eenvoudige, geverifieerde interface die bestaat uit twee methoden: AddPassword (userId, wachtwoord) en Blacklist (spammerUserId).

AddPassword rapporteert eenvoudigweg succes of mislukking. Blacklist voegt de id van de spammer toe aan de zwarte lijst en retourneert een lijst met alle userIds die overeenkomen met het wachtwoord van de spammer. Maar pas op: iedereen die toegang heeft, kan een woordenboek gebruiken tegen uw Blacklist-methode, waardoor legitieme gebruikers worden vergiftigd en lijsten met overeenkomende wachtwoorden worden verzameld.

Intern zou je ze kunnen opslaan zoals je wilt: gehashte, gezouten, gecodeerde of duidelijke tekst. Je moet die machine gewoon veilig op slot houden.

Zoals @AJHenderson al zei, is het simpele antwoord dat je dat niet kunt. Je begrijpt waarom een ​​uniek zout nodig is, en je mist hiervoor geen enkele wiskundige truc, het is echt onmogelijk in combinatie met een uniek zout. Dat gezegd hebbende, dit is hoe ik het probleem zou oplossen:

1. Ik zou een nieuw databaseveld toevoegen met de naam zoiets als UnsaltedPassword en het vullen met alle NULL-waarden. Elke keer dat iemand zijn / haar wachtwoord registreert of wijzigt, vul het dan in met een hash van het wachtwoord, alleen zonder salt en tien keer sterker dan de andere hashing-methode.

2. Wijzig de aanmeldingsprocedure zodat deze controleert of de gebruiker een NULL-waarde in dat veld heeft, en als de gebruiker dat doet, vult u het veld in. Als dit teveel belasting zou veroorzaken, voer de hashfunctie dan alleen uit voor bepaalde accounts, zoals mensen met een lage postcount of gewoon door een willekeurige kans (bijv. Voer de hash uit met een kans van 1 op 10).

3 . Ten slotte zou ik het controleren op dubbele wachtwoorden toevoegen wanneer het veld is gevuld, en ook controleren op een zwarte lijst. Mensen met duplicaten kunnen worden gemarkeerd (mogelijk ook verteld dat ze een zwak wachtwoord gebruiken), en de zwarte lijst wordt onmiddellijk verbannen (of helemaal verboden, indien mogelijk).

Wachtwoordwijzigingen komen niet zo vaak voor in vergelijking met logins (alle keren dat de andere hash-functie met salt moet worden uitgevoerd), dus ik denk dat het logisch is om twee verschillende hash-velden in de database te hebben voor verschillende doeleinden. Ook zou een tien keer sterker moeten kunnen worden gedaan, of misschien zou je zelfs meer kunnen doen (1 tot 2 seconden hashingtijd is waar ik naar streef, aangezien het vrijwel een eenmalige deal is). Het is waarschijnlijk duurder voor aanvallers om deze te kraken dan om alleen het unieke zout toe te passen.