Nee, je hebt gelijk dat je op een bepaald moment tijdens pogingen om te voorkomen dat aanvallers geldige gebruikersidentiteiten bepalen, ofwel tegen hen moet liegen of uitzonderlijk vage foutmeldingen moet geven.

Uw app kan een gebruiker vertellen dat "de gevraagde gebruikersnaam niet beschikbaar is" en niet specifiek aangeven of deze al in gebruik was of gewoon niet voldeed aan uw andere gebruikersnaamvereisten (lengte, tekengebruik, gereserveerd woorden, etc.). Als deze details openbaar zijn, kan een aanvaller er natuurlijk achter komen dat hun gok is mislukt omdat het account in gebruik is en niet vanwege een ongeldig formaat.

Dan heb je ook je wachtwoordherstelsysteem. Accepteert u een gebruikersnaam / e-mailadres en zegt u dat er een bericht is verzonden, zelfs als dat account niet in uw database stond? Hoe zit het met accountvergrendeling (als u deze gebruikt)? Vertel je de gebruiker gewoon dat hun inloggegevens ongeldig waren, zelfs als dat niet het geval was, maar in plaats daarvan werd hun account vergrendeld, in de hoop dat ze contact opnemen met de klantenondersteuning die het probleem kan identificeren?

Het is nuttig om de voor aanvallers is het moeilijk om geldige gebruikersnamen te verzamelen, maar dit gaat meestal ten koste van de gebruikers frustrerend. De meeste van de sites met een lagere beveiliging die ik heb gezien, gebruiken afzonderlijke berichten die aangeven of de gebruikersnaam of het wachtwoord onjuist is, alleen maar omdat ze er de voorkeur aan geven om gebruikers tevreden te houden. U moet bepalen of uw beveiligingsvereisten het voorschrijven om deze prioriteit te geven boven de gebruikerservaring.

U gaat ervan uit dat het systeem werkelijk weet welk veld verkeerd is ingevoerd. Er zijn verschillende redenen waarom dit niet noodzakelijk waar is.

Een mogelijkheid is dat het een bijwerking is van de implementatie. Een simplistische methode om aanmeldingen in een database op te zoeken zou er ongeveer zo uit kunnen zien (gebruik : n voor parameters die door de gebruiker zijn aangeleverd):

  SELECTEER 1 VAN gebruikers WAAR gebruikersnaam = : 1 AND wachtwoord = HASHING_FUNCTION (CONCAT (: 2, salt))  

Als je een leeg resultaat krijgt, weet je dat het inloggen zou moeten mislukken, maar je weet niet waarom, tenzij je dat doet iets ingewikkelder of stel een andere vraag. Dus soms is het misschien gewoon luiheid of de wens om het gemakkelijk te maken met de database, in plaats van een bewuste beveiligingsbeslissing.

Maar zelfs als de implementatie onderscheid kan maken tussen een niet-bestaande gebruiker en onjuiste inloggegevens, heb je nog steeds de situatie waarin een gebruiker zijn wachtwoord correct invoert, maar de verkeerde gebruikersnaam, en dat is toevallig een gebruiker die bestaat (met een ander wachtwoord). Als de gebruiker vervolgens een bericht krijgt dat zijn wachtwoord onjuist was, zou dat verkeerd zijn. Dus tenzij de opgegeven gebruikersnaam niet bestaat, kan het systeem niet echt weten of het de gebruikersnaam of het wachtwoord was dat verkeerd was.

In het algemeen is het moeilijker om een ​​registratiepagina bruut te forceren dan om een ​​inlogpagina bruut te forceren, dus we profiteren van deze extra kosten. Maar in concept heb je gelijk. Er zijn andere manieren om gebruikersnamen op te sommen dan inlogpaginaberichten.

Het is gewoon 'Good Practice' (TM) om foutmeldingen in het loggen algemeen te houden om het voor aanvallers moeilijker te maken om goede accounts van slechte te achterhalen. Met behulp van een brute force-tool is het triviaal om willekeurige namen te proberen, en als de foutmelding verandert, om die gebruikersnaam bruut te forceren.

Maar zoals altijd moet u een evenwicht vinden tussen bruikbaarheid en het verminderen van bedreigingen.

Niet alle systemen hebben accountregistratie. De login van uw besturingssysteem doet dat bijvoorbeeld niet. Websites accepteren van tijd tot tijd geen nieuwe leden meer.

Het is een kwestie van scheiding van zorgen: moet het aanmeldingsvenster de systeemconfiguratie opvragen en het gedrag aanpassen op basis van of het systeem is geconfigureerd om aanvragen voor nieuwe rekeningen of niet? Vervolgens wordt de inlogdialoog gekoppeld aan informatie die niet echt relevant is voor zijn taak.

Het lijkt eenvoudiger om de vage foutmelding in alle gevallen gewoon te implementeren (ervan uitgaande dat de UI-software zelfs weet of het het wachtwoord was dat is slecht, of het account bestaat niet: wat als het een generieke authenticatiefout krijgt van een API op een lager niveau?)

En ook: de nieuwe gebruikersapplicatie UI kan een lange nepvertraging implementeren zoals " zoeken in gebruikersbestand ... [10 seconden] ... oeps, gebruikersnaam is al in gebruik! " Als dat wordt geïmplementeerd, betekent dit dat het doorzoeken van de ruimte van gebruikers-ID's via dit mechanisme ernstig beperkt is. Aangezien het aanvragen van een nieuw account een zeldzame, eenmalige handeling is, zullen gebruikers de vertraging oplopen, terwijl ze verergeren door een vertraging van tien seconden in het normale inlogvenster.

Het hangt ervan af wat de gebruikersnaam is. Er zijn drie hoofdbenaderingen voor gebruikersnamen:

• Door gebruiker geselecteerde naam
• E-mailadres
• Toegewezen gebruikersnaam - meestal een reeks cijfers

Je hebt gelijk dat voor door de gebruiker geselecteerde namen, een aanvaller het registratieproces kan gebruiken om af te leiden welke namen in gebruik zijn, dus het heeft een beperkt voordeel als de login een algemeen bericht retourneert.

Voor de andere twee gevallen is het echter veel belangrijker dat het inlogscherm een ​​generieke foutmelding geeft. Overweeg een rekruteringssite, het zou voor joe.bloggs@abc.com gênant kunnen zijn om zijn baas te laten ontdekken dat er een account op een rekruteringssite is. En toegewezen gebruikersnamen worden het meest gebruikt op zwaarbeveiligde sites zoals online bankieren.

Ja, je hebt gelijk. Overal op uw site waar kan worden bevestigd dat een gebruikersnaam bestaat of niet, kan dit leiden tot opsomming van gebruikersnamen.

dit probleem kan echter worden opgelost als het belangrijk voor uw systeem. Binnen sommige systemen kan de opsomming van gebruikersnamen niet worden vermeden, aangezien dit inherent is aan de aard van de toepassing. Een voorbeeld is een webmailservice - hier worden e-mailadressen als potentieel openbaar beschouwd. Voorkomen dat gebruikers andere gebruikersnamen kennen, is moeilijk zonder dat de gebruikers moeten inloggen met een andere ID dan hun gehoste e-mailadres en kan leiden tot verwarring en problemen bij het herstellen van verloren inloggegevens.

Bij de meeste andere systemen kan dit echter gebeuren. kan worden opgelost door het e-mailadres van de gebruiker als login-gebruikersnaam te hebben. U lost het probleem op door het vergeten wachtwoord en het aanmeldingsformulier op dezelfde pagina te plaatsen. Om u aan te melden, zou dit een formulier met meerdere stappen zijn en de eerste stap vraagt ​​eenvoudigweg om de gebruikersnaam (e-mail) die de gebruiker met uw systeem wil gebruiken. Voor accountherstel zou dit hetzelfde formulier zijn, maar de titel zou iets zeggen in de trant van Voer uw e-mailadres in om een ​​wachtwoordherstel-e-mail te genereren .

In beide gevallen, het formulier stuurt de gebruiker een e-mail. Als ze al zijn aangemeld, bevat de inhoud van deze e-mail een link voor het opnieuw instellen van het wachtwoord. Als ze niet zijn aangemeld, bevat de inhoud van deze e-mail een link naar de volgende fase van het aanmeldingsproces. Dit voorkomt dat gebruikersnamen op uw systeem worden opgesomd, zodat een aanvaller niet weet op welke accounts hij zich moet richten.

Dit betekent natuurlijk dat u bereid bent toe te staan ​​dat wachtwoorden opnieuw worden ingesteld via e-mail, wat voor sommige toepassingen onaanvaardbaar kan zijn zoals banktoepassingen. Aangezien dit soort accounts echter meestal aanvullende beveiligingscontroles heeft, hebben ze meestal een door de bank toegewezen gebruikersnaam in plaats van dat mensen hun eigen namen kunnen kiezen.

Het algemene argument voor vage berichten lijkt te zijn om te voorkomen dat aanvallers geldige gebruikersnamen raden. Er is eigenlijk een eenvoudige oplossing die geen ernstige gevolgen heeft voor legitieme gebruikers, en die hoe dan ook moet zijn: beperk het maximale aantal mislukte pogingen in een bepaalde periode.

Door pogingen te beperken, voorkomt u alle brute- aanvallen forceren. Stel dat u slechts 5 pogingen per 15 minuten toestaat (gebruikelijk op forums) - dat maakt een aanval waarbij de gebruikersnaam wordt geraden vrijwel nutteloos. Het voorkomt ook brute-forcing van wachtwoorden (zo nutteloos traag als dat hoe dan ook op een externe site zou zijn).

Natuurlijk kan een aanvaller al een database met gebruikersnamen hebben en wil hij alleen controleren of ze bestaan op uw site. En je zult de veiligheidsimplicaties daarvan in overweging moeten nemen, maar over het algemeen hebben ze het wachtwoord al (waardoor deze discussie onzeker is) of niet (dus beperkte pogingen voorkomen hoe dan ook gissen).

Een slimme website zou een captcha op hun registratiepagina hebben om dit soort dingen te voorkomen.

Maar je weet hoe 99% van de websites is. Ze zullen hun UX verpesten met een generieke foutmelding, ook al geeft het ze geen extra beveiliging. Persoonlijk doe ik geen moeite met algemene foutmeldingen, aangezien er tal van andere beperkingen gelden voor mijn aanmeldingen (captcha's, beperkte aanmeldingspogingen), en aanmeldingen zijn als de nummer 1 reden waarom mensen een website zullen dumpen.

Als je ervoor kiest om een ​​generiek foutbericht weer te geven, goede god, ga er helemaal voor. Zorg ervoor dat er nergens losse eindjes zijn. Je kunt een muur verstevigen met 25 cm dik staal, maar dat helpt niet als er een deur in zit.

Ik probeer mijn aanvallershoed op te zetten en ik zie 2 gevallen:

1. Je site heeft een registratiepagina (zoals gmail of stackoverflow). Ik zou de registratiepagina kunnen gebruiken om de gebruikersnaam van een bestaande gebruiker met brute kracht te achterhalen. Of ik kan gewoon een nieuwe gebruiker aanmaken. Mijn nieuwe gmail- of stackoverflow-gebruiker zal waarschijnlijk ongeveer dezelfde rechten hebben als degene die ik brute gedwongen zou hebben.

2. Je site heeft geen registratiepagina. Uw punt is ongeldig.

Om de opsomming van de gebruikersnaam op de gebruikersregistratiepagina te vermijden, kan een toepassing de gebruikersnaam automatisch toewijzen op basis van het e-mailadres van de gebruiker, in plaats van de gebruiker te vragen een van zijn keuzes te kiezen.

Op deze manier kan de gebruikersnaam worden voorkomen opsommings- of registratiepagina.

We moeten ook rekening houden met de functionaliteit voor het vergeten van wachtwoorden, soms moet dit ook geldige gebruikersgegevens onthullen.