Ik ben bezig met een login systeem en wil het volgende bereiken.
Als de gebruiker zijn wachtwoord invult en verzend naar de server,
Dan moet de server het wachtwoord voorzien van de salt die wordt gebruikt.
Dus als de gebruiker het wachtwoord 'DitisGeheim' invoert en verzend dan moet de server de salt die aanwezig is met het wachtwoord "mengen".
Bijv :
ww : DitisGeheim ( min 6 chars, max 20 chars )
salt : MiJnS@lT# ( let op dit is een voorbeeld salt ! )
Resultaat : lD#itTiMsGeiheJim@
De salt moet telkens op dezelfde plekken in de string van de gebruiker komen.
Dit wil ik afhankelijk van de lengte van het wachtwoord laten zijn.
Omdat natuurlijk niet iedereen dezelfde lengte heeft als wachtwoord.
Nu heb ik voorbeelden gezien die "sub_str" gebruiken maar ik weet nog niet helemaal welke richting ik moet zoeken.
Hopelijk kan iemand mij in de juiste richting helpen zodat ik beetje kan uittesten wat wel of niet zal werken.
Waarom zou je dit uberhaupt willen? Het wordt er niet veiliger van dan wanneer je de salt in zijn geheel voor of achter het wachtwoord zet, maar is wel een stuk ingewikkelder te coderen.
Heej willem, ik was aan het nadenken om ervoor te zorgen dat als er iets gebeurt ik de gegevens voor zover mogelijk extra beveilig.
Maar nu ik er zo over nadenk zal dat niet echt oplossing zal zijn.
Probeer dan een manier te bedenken om voor elke gebruiker een andere salt te gebruiken, die je niet in de database opslaat. Bijvoorbeeld de salt op te bouwen uit andere gegevens van de gebruiker.
Ik dacht misschien aan de datum van registratie en eventueel email deze door elkaar halen.
Maar ik dan heb ik weer het idee dat iedereen onnodig vind enzo.
Tenzij je een cryptografische expert bent moet je niet zelf iets proberen te maken.
Gebruik Bcrypt via de password_hash() functie.
<?php
include 'config/bcrypt.php'; // haal de cost op
#### registratie ####
// wijzig/maak hash
// genereert zelf een unieke salt
$hash = password_hash($password, PASSWORD_BCRYPT, array('cost' => $cost /* 12 is wel goed atm */));
#### login ####
// vergelijk wachtwoord met hash
if (password_verify($password, $hash /* komt uit de database */))
{
// goede wachtwoord opgegeven
// controleer of hash met de meest recente configuratie gehashed is
if (password_needs_rehash($hash, PASSWORD_BCRYPT, array('cost' => $cost)))
{
// hash was gehashed met een andere cost, deze moet dus geupdate worden
$hash = password_hash($password, PASSWORD_BCRYPT, array('cost' => $cost));
// zet nieuwe hash in de database...
}
// log de gebruiker in, zet session, cookies etc
}
else
{
// verkeerd wachtwoord opgegeven
}
?>
En het liefst is je website alleen via https bereikbaar zodat het plaintext wachtwoord zo veilig mogelijk naar de server verstuurt wordt.
Edit: de cost en salt worden trouwens in de hash opgeslagen. http://3v4l.org/dMigk
$2y$ geeft aan dat het een bcrypt hash is
de volgende 2 cijfers zijn de cost (04-31)
$
de volgende 22 tekens zijn de salt
de rest kun je zien als de 'echte' hash
De salt is geen geheim, deze moet alleen uniek zijn.
Door dat die twee dingen in de hash verwerkt zijn gebruik password_verify() de gegevens in de hash waarmee je wilt vergelijken om het opgegeven wachtwoord mee te hashen. De cost voor nieuwe hashes veranderen heeft dus geen invloed op oude hashes.
Door tijdens het inloggen met password_needs_rehash() te controleren of het opgegeven algoritme met de opgegeven waardes gebruikt is kun je hashes stilletjes upgraden naar een betere versie.
Als je gewoon zonder https een wachtwoord verstuurt, dan wordt dat wachtwoord toch als plaintext verstuurt?
Je kan dan wel allemaal daar versleutingen en hashes op gooien, maar wat binnen komt blijft wat binnenkomt
Het wachtwoord wordt altijd als plaintext verstuurd via HTTP. Als je het clientside gaat hashen is de hash het echte wachtwoord, en die wordt gewoon als zichzelf verstuurd...
https voegt encryptie toe waardoor een man-in-the-middle aanval nodig is om achter het plaintext wachtwoord te komen wat een stuk moeilijker is dan alleen packets onderscheppen en het plaintext wachtwoord uit te lezen.
https voegt encryptie toe waardoor een man-in-the-middle aanval nodig is om achter het plaintext wachtwoord te komen wat een stuk moeilijker is dan alleen packets onderscheppen en het plaintext wachtwoord uit te lezen.
nee, waardoor het juist *niet* meer mogelijk is om een MITM aanval uit te voeren. juist zónder SSL-certificaat is het plaintext te zien.
Bedankt voor het voorbeeld en de uitleg.
Ik gebruik op dit moment een AES class om het wachtwoord te beveiligen.
Is er eventueel ook een manier om met php of js het wachtwoord te encrypten voordat deze "echt" verzonden wordt naar de server om het "niet als plaintext" te verzenden ?
De reden dat ik dit vraag is omdat ik ooit ergens een js encrypt functie heb gezien. ( niet echt gelezen wat het doet. )
