Met Apache is het vrij eenvoudig om een pagina op te zetten die basistoegangsverificatie gebruikt om een gebruiker om een naam/wachtwoord te vragen en die inloggegevens op een of andere manier te gebruiken om toegang te verlenen aan die gebruiker.
Is dit veilig, ervan uitgaande dat de verbinding tussen de client en de server veilig is?
Antwoord 1, autoriteit 100%
De zorg over basisverificatie is dat de inloggegevens als leesbare tekst worden verzonden en kwetsbaar zijn voor pakketsniffing. Als die verbinding is beveiligd met TLS/SSL, is deze net zo veilig als andere methoden die codering gebruiken.
Antwoord 2, autoriteit 41%
Dit is een oude thread en ik geloof niet dat het meest gestemde/gekozen antwoord juist is.
Zoals opgemerkt door @Nateowami, de thread voor uitwisseling van beveiligingsstacksschetst een aantal problemen met basisverificatie.
Ik wil nog op een andere wijzen: als u uw wachtwoordverificatie correct uitvoert, maakt basisverificatie uw server kwetsbaarder voor denial of service. Waarom? Vroeger geloofde men dat gezouten hash voldoende was voor wachtwoordverificatie. Dat is niet langer het geval. Tegenwoordig zeggen we dat je langzame functies nodig hebt om brute force-wachtwoorden te voorkomen in het geval dat de database wordt blootgesteld (wat maar al te vaak gebeurt). Als u basisverificatie gebruikt, dwingt u uw server om deze trage berekeningen uit te voeren bij elke API-aanroep, wat een zware last voor uw server vormt. Je maakt het kwetsbaarder voor DoS door simpelweg dit verouderde authenticatiemechanisme te gebruiken.
Meer in het algemeen hebben wachtwoorden een hogere waarde dan sessies: het compromitteren van een gebruikerswachtwoord maakt het mogelijk om het account van de gebruiker voor onbepaalde tijd te kapen, om nog maar te zwijgen van de mogelijkheid om andere systemen te kapen waartoe de gebruiker toegang heeft vanwege hergebruik van wachtwoorden; terwijl een gebruikerssessie in de tijd beperkt is en beperkt is tot een enkel systeem. Daarom, als een kwestie van diepgaande verdediging, mogen waardevolle gegevens zoals wachtwoorden niet herhaaldelijk worden gebruikt als dit niet nodig is. Basisverificatie is een verouderde technologie en moet worden afgeschaft.
Antwoord 3, autoriteit 7%
De reden waarom de meeste sites OAuth verkiezen boven Basic Auth, is dat Basic Auth gebruikers vereist om hun wachtwoord in een app van derden in te voeren. Deze app van derden moet het wachtwoord in leesbare tekst opslaan. De enige manier om de toegang in te trekken is door de gebruiker zijn wachtwoord te wijzigen. Dit zou echter de toegang voor alle apps van derden intrekken. Dus je kunt hier zien wat het probleem is.
Aan de andere kant vereist OAuth een webframe. Een gebruiker voert zijn inloggegevens in op de inlogpagina van deze specifieke site zelf. De site genereert vervolgens een toegangstoken waarmee de app zichzelf in de toekomst kan authenticeren. Voordelen:
- een toegangstoken kan worden ingetrokken
- de app van derden kan het wachtwoord van de gebruiker niet zien
- aan een toegangstoken kunnen bepaalde machtigingen worden verleend (terwijl basisverificatie elke consument gelijk behandelt).
- Als een app van derden onveilig blijkt te zijn, kan de serviceprovider besluiten alle toegangstokens die voor die specifieke app zijn gegenereerd, in te trekken.
Antwoord 4, autoriteit 3%
Basisverificatie via http in een omgeving die kan worden gesnoven, is hetzelfde als geen verificatie, omdat het wachtwoord eenvoudig kan worden teruggedraaid en vervolgens opnieuw kan worden gebruikt. Als reactie op de spottende opmerking hierboven over creditcards via ssl die “een beetje” veiliger zijn, is het probleem dat basisauthenticatie steeds opnieuw via hetzelfde kanaal wordt gebruikt. Als u het wachtwoord eenmaal compromitteert, brengt u de beveiliging van elke transactie via dat kanaal in gevaar, niet alleen een enkel gegevenskenmerk.
Als u wist dat u tijdens een websessie steeds hetzelfde creditcardnummer zou doorgeven, zou ik hopen dat u een andere controle zou bedenken dan alleen op SSL te vertrouwen, want de kans is groot dat een tegoed kaartnummer dat vaak wordt gebruikt, zal worden gecompromitteerd… uiteindelijk.
Antwoord 5
Als je wachtwoorden genereert met htpasswd, overweeg dan om over te schakelen naar htdigest.
Digest-authenticatie is veilig, zelfs via niet-versleutelde verbindingen en is net zo eenvoudig in te stellen. Natuurlijk, basisauthenticatie is oké als je over ssl gaat, maar waarom zou je het risico nemen als je net zo gemakkelijk digest-authenticatie kunt gebruiken?
Antwoord 6
Zoals de naam zelf al aangeeft, is ‘Basic Authentication’ slechts een basisbeveiligingsmechanisme. Vertrouw er niet op om u zorgeloze beveiliging te bieden.
Het gebruik van SSL maakt het iets veiliger, maar er zijn betere mechanismen.