Dit heeft niks te maken met PHP of websites maar wel met SQLite.
Ik heb de volgende query:
SELECT * FROM `USERS` WHERE `USERNAME` = '%s' AND `PASSWORD` = sha1('%s')
Helaas resulteert dit in het verkeerde wachtwoord. Waarom eigenlijk? De code waar ik mee werk ondersteund sha1.
Wij gebruikte eerst md5 (aantal jaartjes geleden geschreven omdat wij toen nog niet van dingen zoals sha1 af wisten.) en dit werkte prima met dit:
SELECT * FROM `USERS` WHERE `USERNAME` = '%s' AND `PASSWORD` = md5('%s')
%s is een string trouwens die achter de query wordt aangeroepen.
Helaas heeft onze game niks om bijv zoals in php dit te doen:
<?php
$str = "Hello";
echo sha1($str);
?>
Het is dus noodzakelijk om dit in de query zelf uit te voeren in plaats van de string aan te passen.
Hoe kan dit eigenlijk? Op de website kan je wel gewoon inloggen doormiddel van sha1. Kan het zo zijn dat sqlite sha1 niet ondersteund? Maarja, op de website gaat de query dan ook totaal anders:
$postedpassword = sha1($_POST["PASSWORD"]);
$sql = "SELECT * FROM USERS WHERE USERNAME LIKE '$postedusername' AND PASSWORD = '$postedpassword'";
SHA1 is al weer achterhaald, maar waarom zou je het niet in de code kunnen opvangen?
Voor SHA1 kan dit al sinds PHP 4.
Verder kan je niet zomaar encrypted passwords omzetten naar een andere encryptie. Want je encrypt daarmee tenslotte de hash zelf. En dat is niet het wachtwoord wat de gebruiker invoert.
De enige oplossing is om alle wachtwoorden te resetten in een random string en de accounts te deactiveren, en een visuele interface te bouwen die gebruikers na mailverificatie een nieuw password laat invullen.
Persoonlijk raad ik [php]password_hash[/php] en [php]password_verify[/php] aan om te gebruiken.
Het kan niet in de code worden opgevangen omdat het niet om php gaat.
PHP heeft bijvoorbeeld veel ingebouwde functies zoals md5() en sha1() maar in de code waar wij mee werken is dit helaas niet het geval.
In PHP werkt het perfect. Het gaat hier puur om het inlog gedeelte in de game zelf. Nu heb ik begrepen dat in de query sha1() ook zou moeten werken maar bij mij werkt dit niet op de een of andere manier.
Sorry als ik je verkeerd begrijp maar volgensmij heb ik iets niet helemaal goed uitgelegd.
Bijv:
`PASSWORD` = sha1('%s')
%s haalt het ingevoerde wachtwoord op en zou dat dan moeten vergelijken met PASSWORD.
Maar wat nou gebeurd eigenlijk is dat als je het wachtwoord 1234 invult, PASSWORD word vergeleken met 1234 inplaats van de encrypted version. Het lijkt net alsof er niets is gebeurd met het ingevulde wachtwoord, of misschien dat hij hem wel letterlijk als dit leest zonder iets te encrypted:
`PASSWORD` = sha1('1234')
De suggesties over password_hash en password_verify zijn php functies en helaas voor mij niet van toepassing omdat er meerdere systemen op de zelfde manier moeten kunnen inloggen met hetzelfde wachtwoord.
md5() en sha1() zitten al jaren in PHP hoor, dus die kan je gewoon gebruiken. Of je moet een zwaar-bejaarde PHP-versie draaien van versie 4, wat ik echt niet hoop :-P
Stap liever van SHA1 en MD5 af, want het is gewoon niet veilig, ongeacht wat je precies wilt met een ledenadministratie.
Volgensmij heb je me niet goed begrepen want ik ben hier niet in php aan het coderen zoals ik al aangaf. In php gebruik ik deze gewoon en werkt dit prima. Maar dit gaat niet om PHP
[size=xsmall]Toevoeging op 24/03/2018 15:28:35:[/size]
Volgensmij heb je me niet goed begrepen want ik ben hier niet in php aan het coderen zoals ik al aangaf. In php gebruik ik deze gewoon en werkt dit prima. Maar dit gaat niet om PHP
Welke taal dan? Als je dat nou vanaf begin af aan vermeldt, dan was het een stuk helderder. Want ik neem aan dat die vast wel een betrouwbaar encryptiealgoritme zal kennen.
SELECT `PASSWORD`, sha1('%s') FROM `USERS` WHERE `USERNAME` = '%s'
Wat zie je dan? Helemaal niet gelijk, of wel/geen hoofdletters (en een case sensitive collation)? Is de lengte wel gelijk (anders is PASSWORD misschien helemaal niet met sha1 gehashed)?
@Jasper: leer eerst eens het verschil tussen encryptie en hashing. Hashing is niet omkeerbaar. Daarom lijkt het mij ook sterk dat je "bent overgestapt van MD5 naar SHA1". Dit zou namelijk inhouden dat alle gebruikers een nieuw (of hetzelfde) wachtwoord op hebben moeten geven, want met het bezit van de hashes van wachtwoorden bezit je niet de originele wachtwoorden. Dat is juist het hele punt: de partij die de wachtwoorden opslaat doet dit in gehashde vorm... Voer de test van @Rob eens uit, onderzoek eens wat er nu daadwerkelijk aan de hand is.
Daarnaast is SHA1 gewoon SHA1 lijkt mij, dit is een standaard, dus het lijkt mij sterk dat twee verschillende technieken verschillende implementaties zouden hebben van SHA1, dat zou het hele principe om zeep helpen...
(en serieus, een query met WHERE USERNAME LIKE???)
Mogelijk ondersteunt SQlite geen SHA1 - heb je dit al geGoogled? eerste resultaat (geldigheid van de informatie onbekend)... maareh? Probeer eens wat uit?
EDIT: en als SHA1 standaard niet ondersteund wordt in SQLite, dan verplaats je het hashen toch gewoon naar PHP, of je gebruikt direct een betere oplossing voor wachtwoord-beveiliging.
Wat me eigenlijk ook weer terugbrengt bij de database-keuze, waarom gebruikte je ook alweer SQLite?
