[CMS] Websitebaker Wachtwoord decrypt

[MdemiC]

Hallo,

Ik ben bezig met een websitebaker website en daarnaast moet een website draaien die op de database van websitebaker werkt.

Nu heb ik gezien dat in de websitebaker login een hash van je wachtwoord gemaakt word en ook in de database gestopt word.

Nu is mijn vraag of iemand hier (omdat het forum van websitebaker tijdelijk down is) ervaring heeft met websitebaker en het wachtwoord te decrypten.

Ik heb google en de Tweakers Search geprobeert maar ik kan niks vinden.


Zou iemand mij hier mee kunnen helpen?!


Groetjes

Bob

[RobIII]

Een hash != encryptie. Een hash kun je dus niet "decrypten"*. Punt.

Je zult dus een andere weg moeten kiezen; bijvoorbeeld:
a) De tweede website via een een HTTP call naar de eerste website de gegevens laten valideren door de eerste website
b) Simpelweg door website B dezelfde hash (+ evt. salt!) toe te passen op 't ingevoerde wachtwoord en deze uitkomst te vergelijken met de hash uit de DB van de eerste website


* Tenzij je een zwakke hash functie hebt gebruikt met bekende issues of een brute-force op een hash wil beschouwen als "decryptie". Wat overigens dan nog steeds mogelijk een collision oplevert en niet de daadwerkelijke hashed text.

[ Voor 103% gewijzigd door RobIII op 18-03-2013 14:45 ]

[MdemiC]

Dankje wel voor je antwoord maar ik was iets te snel met een topic maken.

Ik heb niet simpel geprobeert om inteloggen met me eigen inlog script (md5) decrypter.

sorry voor het ongemak.

[SLOTJE]

[RobIII]

Een slotje is niet nodig op een topic als je je oplossing hebt. Zie daarvoor ook onze faq betreffende topiceinde.

[phex]

Overigens ben ik wel benieuwd hoe jij aan het gehashte wachtwoord komt.

Als je bij de db kan, kun je toch net zo goed het wachtwoord opnieuw genereren als je code bekijkt die het wachtwoord maakt?

Lijkt me makkelijker dan met rainbow tables te werken, zeker als het wachtwoord gesalt wordt.

[MdemiC]

Ik keek de code door en ik (dacht) dat het een eigen gemaakte hash was. Toen ik een eigen pagina maakte met inlog script die het wachtwoord uit de database haalt en dan door de php functie md5() haalt en dan controleert of het wachtwoord overeenkomt met het wachtwoord uit de database.
//Mijn login script

PHP:

    $username=mysql_real_escape_string($_POST['username']); 
    $password=mysql_real_escape_string($_POST['password']); 
    $password=md5($password); // Encrypted Password
    $sql = "SELECT user_id FROM `wb_users` WHERE username='$username' and password='$password'";
    $result=mysql_query($sql);
    $count=mysql_num_rows($result);

    // If result matched $username and $password, table row must be 1 row
    if($count==1)
    {
        // Register $username, $password and redirect to file "qreditpage.php"
        session_register("username");
        session_register("password");
        header("location: qreditpage.php");
    }

//Login script van Websitebaker

PHP:

    $username_fieldname = 'username_';
    $password_fieldname = 'password_';
    $salt = "abchefghjkmnpqrstuvwxyz0123456789";
    srand((double)microtime()*1000000);
    $i = 0;
    while ($i <= 7) {
        $num = rand() % 33;
        $tmp = substr($salt, $num, 1);
        $username_fieldname = $username_fieldname . $tmp;
        $password_fieldname = $password_fieldname . $tmp;
        $i++;
    }

Het kan zijn dat ik helemaal verkeert zat te kijken en dat ik het gewoon helemaal fout had maar soms denk ik niet zo goed na.

Als nog bedankt iedereen

[CyberJack]

beetje offtopic, maar plain (zonder salt) md5 beveiliging is tegenwoordig echt niet meer voldoende.
md5 en sha1 zijn beide af te raden voor het opslaan van wachtwoorden.

Beter is het gebruik te maken van bcrypt i.c.m. een sha256 hash.

[ReenL]

Script slaat ook nog eens de "hashed" variant op in een cookie sessie, de ingevoerde gebruikersnaam komt in het cookie de sessie in plaats van die uit de database en mysql_real_escape_string wordt gedaan voor het hashen. Allemaal dingen waarvan je kan zeggen "het werkt toch" en "dat kan toch niet zoveel kwaad", maar het geeft wel het niveau aan. Nu maar hopen dat er verder niets belangrijks op die server te vinden is.

[ Voor 3% gewijzigd door ReenL op 20-03-2013 14:12 . Reden: fixed Cookie -> sessie ]

[CyBeR]

Euh. Twee dingen:
• Een wachtwoord md5'en en in een db stoppen is onveilig. Prop die md5 in google en binnen luttele seconden heb je een rainbow table met die hash en dus het wachtwoord (of equivalent) te pakken.
• Die code van je websitebaker doet beduidend meer dan alleen md5(password) in de database stoppen, precies om bovenstaand te voorkomen. Die hashes zijn niet te reversen.

ReenL: nee, hij zet 't in de session. Dat kan al minder kwaad maar nog steeds is 't vrij nutteloos. (Iemand die de sessions uit kan lezen op de server kan daarmee de hash achterhalen, zelfs al kan 'ie niet in de db.)

[ Voor 22% gewijzigd door CyBeR op 19-03-2013 20:06 ]

[Cartman!]

Nog een ding: session_register en mysql_* zijn beiden depricated en zullen dus niet meer werken als je host n update krijgt. Verder zie ik geen enkele reden om het password(hashed of niet) in de sessie op te slaan, gewoon niet doen.

Tldr; opnieuw maken en goed de handleidng lezen. Bij specifieke vragen kun je ze hier stellen

[CyberJack]

session_register zit al niet meer in 5.4 (en als je host update heb je inderdaad een probleem).
mysql_* is depricated vanaf 5.5.0 en zal in een latere versie verdwijnen. Voorlopig zal geen hoster 5.5 draaien omdat die nog in de alpha releases zit (alpha 6 momenteel).

mysql_* is dus niet gelijk een probleem, al ben ik persoonlijk van mening dat dit al lang niet meer gebruikt moet worden. Op zijn minst mysqli of pdo.

Maar inderdaad goed advies, handleiding lezen en opnieuw maken.

[MueR]

Cartman! schreef op woensdag 20 maart 2013 @ 15:36:
Nog een ding: session_register en mysql_* zijn beiden depricated en zullen dus niet meer werken als je host n update krijgt.

Geen enkele fatsoenlijke hoster gaat in het komende jaar automagisch upgraden naar 5.5 tbh. Daarmee breken ze veel te veel sites.

[Cartman!]

MueR schreef op woensdag 20 maart 2013 @ 17:10:
[...]

Geen enkele fatsoenlijke hoster gaat in het komende jaar automagisch upgraden naar 5.5 tbh. Daarmee breken ze veel te veel sites.

Uiteraard, maar als je nu nog functies gaat gebruiken die al een tijdje depricated zijn ben je gewoon niet handig bezig, volgens mij hoeven we daar geen discussie over te voeren.

[Freeaqingme]

MueR schreef op woensdag 20 maart 2013 @ 17:10:
[...]

Geen enkele fatsoenlijke hoster gaat in het komende jaar automagisch upgraden naar 5.5 tbh. Daarmee breken ze veel te veel sites.

Dat weet ik niet? Die deprecation notices zijn slechts notices die met error reporting levels redelijk te tunen zijn. Als ze by default geen notices tonen zit je vanuit dit perspectief wel safe.

[CyberJack]

Freeaqingme schreef op donderdag 21 maart 2013 @ 12:00:
[...]
Als ze by default geen notices tonen zit je vanuit dit perspectief wel safe.

Het gebruik van depricated functies staat los van of een provider dit wel of niet laat zien.
Depricated functies moet je eigenlijk uit je bestaande code halen en moeten zeker niet gebruikt worden voor nieuwe ontwikkelingen. De functies zijn niet voor niets depricated en er zijn inmiddels genoeg betere en vaak uitgebreidere alternatieven.

[Freeaqingme]

cyberjack77 schreef op donderdag 21 maart 2013 @ 16:51:
[...]


Het gebruik van depricated functies staat los van of een provider dit wel of niet laat zien.
Depricated functies moet je eigenlijk uit je bestaande code halen en moeten zeker niet gebruikt worden voor nieuwe ontwikkelingen. De functies zijn niet voor niets depricated en er zijn inmiddels genoeg betere en vaak uitgebreidere alternatieven.

Absoluut waar (hoewel php er ook een handje van heeft om soms deprecated features te undeprecaten). Maar als iemand lokaal developt, dan zou 'ie dat met error reporting aan moeten doen, en daar de deprecationnotices moeten tegenkomen. Op productie - de omgeving van de webhost - zouden deze sowieso uit moeten staan, en betekent het deprecaten van features dus niet meteen het breken van functionaliteit .