[PHP&MySQL] Paswoord systeem*

[Carnifex]

Ik kan het niet vinden in de search, dus 'here we go':

Ik heb een website gemaakt waar je in kunt loggen en vervolgens diverse POP emailadressen kunt controleren. Probleem is dat je op al die POP servers een wachtwoord moet hebben dat ik dus wil opslaan in de MySQL database (waar dus de rest van de server-info ook staat). Een beetje ala de POP-service van Hotmail dus . Hoe sla ik die w8woorden gecodeerd op in mijn database en hoe haal ik die dan weer terug (kon alleen topics over hash-passwords vinden)? Ik kan op php.net geen antwoord vinden en mysql.com lijkt down .
Het kan natuurlijk ook zo zijn dat ik het beter manier is om dit probleem op te lossen waar ik nog niet aan heb gedacht.

[oeps]
DAMN topic vergeten! kan iemand er iets moois van maken? thanxz! ('password retrieval' of zoiets)
[/oeps]

[Pjottski]

http://www.php.net/manual/en/function.md5.php

[Carnifex]

Calculates the MD5 hash

Laat ik nu net geen hash willen gebruiken. Ik gebruik wel MD5 bij het inloggen op de site zelf. De bedoeling is dat je met 1 wachtwoord al je email-accounts kan checken, zonder al die wachtwoorden daarvoor in te hoeven tikken.

[Janoz]

md5 gaat niet werken aangezien dat 1-way is.

Het gecodeerd opslaan van de wachtwoorden heeft waarschijnlijk weinig nut. Je hebt de orginele wachtwoorden nodig om in te loggen op de POP servers en een hashing techniek is dus niet mogelijk. Ook andere technieken zijn wat lastig want waneer iemand bij de DB kan kan ie ook in de scripts lezen hoe het wachtwoord weer gedecodeerd kan worden.

Mischien is het een ID om de wachtwoorden te versleutelen met het wachtwoord van de gebruiker. Maar dan zul je dat wachtwoord in bv een sessie moeten opslaan, en deze is ook weer te lezen..

Er zit waarschijnlijk weinig anders op dan die wachtwoorden gewoon plain in de DB op te slaan.

[Carnifex]

Hoe doen ze dat bij hotmail dan?

[eamelink]

Op donderdag 27 juni 2002 17:05 schreef Carnifex het volgende:
Hoe doen ze dat bij hotmail dan?

Waarschijnlijk ook plaintext opslaan.

[ET]

Op donderdag 27 juni 2002 17:05 schreef Carnifex het volgende:
Hoe doen ze dat bij hotmail dan?

Daar log je toch in met je naam en wachtwoord, dus dat kan hij dan 1-richting encoden en dan matchen met het ge-ecncodeerde wachtoord in de DB. (dus in die DB staat dan niet nog een keer een ander wachtwoord.)

[whoami]

Op donderdag 27 juni 2002 17:18 schreef eamelink het volgende:

[..]

Waarschijnlijk ook plaintext opslaan.

Dat zou me toch echt wel verbazen hoor. Waarom zou je een wachtwoord als plain text willen opslaan?
Je kunt toch - als het nodig is - zelf een encrypt en decrypt functie schrijven om die wachtwoorden te versleutelen. Iemand die de databank in handen krijgt is er dan niets mee, hij moet al de decrypt functie te pakken krijgen EN hij moet ook nog begrijpen wat die doet. (En daarnaast moet hij ook nog eens de key in handen krijgen).

[Crazy D]

Op donderdag 27 juni 2002 17:20 schreef whoami het volgende:
Dat zou me toch echt wel verbazen hoor. Waarom zou je een wachtwoord als plain text willen opslaan?

Lekker makkelijk?
Ik denk omdat "ze" er vanuit gaan dat als je bij de db kunt komen, je ook de scripts kunt checken, en dus ook de boel kan decrypten... mjah is er nog steeds wel wat voor te zeggen om het toch te encrypten, dus ik weet het eigenlijk niet. Misschien een volledig en blind vertrouwen in de firewall en andere beveiligingen?

[ET]

Op donderdag 27 juni 2002 17:38 schreef Crazy_D het volgende:

[..]

Lekker makkelijk?
Ik denk omdat "ze" er vanuit gaan dat als je bij de db kunt komen, je ook de scripts kunt checken, en dus ook de boel kan decrypten... mjah is er nog steeds wel wat voor te zeggen om het toch te encrypten, dus ik weet het eigenlijk niet. Misschien een volledig en blind vertrouwen in de firewall en andere beveiligingen?

Microsoft gelooft inderdaad in hun beveiliging (Volgens mij geloven ook alleen zij in hun beveiligng )

[Feyd-Rautha]

Op donderdag 27 juni 2002 17:38 schreef Crazy_D het volgende:

[..]

Lekker makkelijk?
Ik denk omdat "ze" er vanuit gaan dat als je bij de db kunt komen, je ook de scripts kunt checken, en dus ook de boel kan decrypten...

Maar toch vergt het nog enige moeite om alles te decrypten. Wat toch al de niet zo volhardende hacker kan afhouden.

[Sjab-X]

Heb je misschien iets aan mcrypt-encrypt en mcrypt-decrypt?

[corani]

Je zou het wachtwoord waar de gebruiker mee inlogd kunnen gebruiken om de wachtwoorden van de verschillende POP-servers mee te coderen. Van het inlogwachtwoord sla je natuurlijk alleen de MD5 op.

Dus..

- gebruiker logt in (username, password)
- md5(password) vergelijken met database
- indien okay, gebruiker = ingelogd.
- pop instellingen uit database halen
- pop-password decoderen met password
- pop ophalen

[Verwijderd]

Op donderdag 27 juni 2002 18:55 schreef Sjab-X het volgende:
Heb je misschien iets aan mcrypt-encrypt en mcrypt-decrypt?

Of base64_encode()/base64_decode(), maar dit is zo makkelijk voor iemand te decoden...

[Janoz]

Op donderdag 27 juni 2002 19:03 schreef corani het volgende:
- gebruiker logt in (username, password)
- md5(password) vergelijken met database
- indien okay, gebruiker = ingelogd.
- pop instellingen uit database halen
- pop-password decoderen met password
- pop ophalen

Dan zul je toch het werkelijke wachtwoord van de gebruiker moeten onthouden terwijl deze is ingelogd. Hiervoor zul je dan iets session-achtigs moeten gebruiken, en deze zijn ook wel weer toegankelijk (als iemand bij je DB kan komen kan ie ook wel bij de sessies komen. Deze staan namelijk of in de DB of (waneer je de standaard php session methodes gebruikt) gewoon op de harde schijf van de server.

[LuCarD]

Op donderdag 27 juni 2002 19:19 schreef int het volgende:

[..]

Of base64_encode()/base64_decode(), maar dit is zo makkelijk voor iemand te decoden...

Dat is niet echt wat je zegt een beveiliging......

Er zijn trouwens meerdere malen een aantal topics langs geweest mbt tot encryptie misschien. Sommige met complete scripts. Misschien kan je daar wat lenen?

[Carnifex]

- gebruiker logt in (username, password)
- md5(password) vergelijken met database
- indien okay, gebruiker = ingelogd.
- pop instellingen uit database halen
- pop-password decoderen met password
- pop ophalen

Is inderdaad het idee en

Heb je misschien iets aan mcrypt-encrypt en mcrypt-decrypt?

Is inderdaad de oplossing denk ik (nu), maar dankzij jullie weet nu dat dit de enige oplossing is en dat ik het hier maar mee ga doen .

[Carnifex]

Ik zit toch eigenlijk nog met een probleempje... Het is niet de bedoeling dat de beheerder van de site (of iemand anders natuurlijk) de passwords kan zien. Ik heb een beetje gekeken bij die funcites in PHP om iets te coderen/decoderen en heb gezien dat dat vaak met een 'key' gaat. Kan ik niet op een of andere manier die 'key' genereren uit het password van iemand?

Ik denk dat niemand zijn wachtwoorden ergens laat opslaan waar ze door iemand anders dan hun op te vragen zijn... ik zou het niet doen iig

[Vigory]

Ik ga binnenkort ook zoiets bouwen, maar ik laat alleen de pop server, username enzo opslaan, niet het wachtwoord. Dat moeten ze elke keer zelf intikken.

Als je net zoiets wil als bij Hotmail dat op de achtergrond werkt kan dat natuurlijk niet, maar voor webmail zou ik het op deze manier doen.

[Verwijderd]

Wat je zou kunnen doen is het volgende:

User password (om in te loggen) MD5 opslaan in de database.
Als de user inlogd zijn password controleren en als dat okee is zijn POP passwords ophalen.

Deze passwords dycrypen en in zijn sessievariabelen opslaan, als jij op een link klikt ofzo om zijn mail te checken deze sessievars gebruiken

de POP passwords zou je met behulp van deze functies kunnen encrypten in de db:

- Encrypt
- Decrypt

De encryption key kan je bv uit de username/password combinatie halen.

Geen idee of dit gaat werken, maar het zijn wel leuke dingen om mee te stoeien!

Succes

[Eguan]

Ik heb ooit eens zoiets gemaakt:

code:

<?PHP

if ($Submit) {

include("../config.inc");
mysql_connect("$db_connect","$db_username","$db_password");
mysql_select_db("$database");

    $username = ($username);
$password_crypted = crypt($password,"AB");
$query = mysql_query("SELECT * FROM users WHERE username='$username' AND password='$password_crypted'");
    $results = mysql_num_rows($query);

if ($results == 1) {

        $login = "blahblah";
      session_register("login");

        Header("Location: index.php");

      }
      else {

Header("Location: index.php?page=login");

} }
?>

Dit is alleen het stukje voor het inloggen. Op deze wijze heb ik ook een gebruiker toegevoegd.

Het zit zelfs zo in elkaar dat je IP's kan toevoegen en wanneer je vanaf dat IP wil inloggen dan doet ie dat automatisch

[Carnifex]

Op zaterdag 29 juni 2002 11:51 schreef IceFlame het volgende:
Wat je zou kunnen doen is het volgende:

User password (om in te loggen) MD5 opslaan in de database.
Als de user inlogd zijn password controleren en als dat okee is zijn POP passwords ophalen.

Deze passwords dycrypen en in zijn sessievariabelen opslaan, als jij op een link klikt ofzo om zijn mail te checken deze sessievars gebruiken

de POP passwords zou je met behulp van deze functies kunnen encrypten in de db:

- Encrypt
- Decrypt

De encryption key kan je bv uit de username/password combinatie halen.

Geen idee of dit gaat werken, maar het zijn wel leuke dingen om mee te stoeien!

Succes

Dat is dus ook hoe ik er over denk. Ik zie alleen wel een probleem in het stukje van de 'key' die je aanmaakt met behulp van een username/password combiatie. Ik kan zelf geen manier verzinnen om het zo te maken dat IK, de maker van het PHP spul, er zelfs niet achter kan komen wat de w8woorden van anderen zijn. Het probleem is dat ik overal toegang toe heb in de database omdat ik als root kan inloggen en precies weet wat er allemaal in de PHP documenten gebeurt (nouja probleem ).

Ik zou dus eigenlijk de key op moeten slaan als MD5 in de database, of de key gelijkstellen aan het login password van de site(dat natuurlijk ook als MD5 opgeslagen is). Vervolgens moet ik dan met die ongecodeerde key de email-login-wachtwoorden ophalen uit de database. Is het niet gevaarlijk om een variable op te nemen waarin het ongecodeerde login-wachtwoord is opgeslagen? En als het onveilig is, op welke manier is dat dan onveilig? Dat iemand die ingelogd is zijn eigen wachtwoorden kan zien of waar moet ik aan denken? Hoe kun je variabelen opvragen uit het $_SESSION['...'] gedeelte als geen controle hebt over de code (iemand die dus op de site surft)?

[Verwijderd]

Of base64_encode?

[ACM]

Op zaterdag 29 juni 2002 20:22 schreef daniel_hoenderdos het volgende:
Of base64_encode?

Dat is absoluut geen manier om de boel veilig op te slaan en daar ook niet voor bedoelt

[Verwijderd]

Weet ik wel, maar ik kwam toevallig in een enigszins antiek stukje code die functie tegen om passwords te versleutelen.
Waarom is het trouwens niet veilig?

[ACM]

Op zondag 30 juni 2002 15:58 schreef daniel_hoenderdos het volgende:
Weet ik wel, maar ik kwam toevallig in een enigszins antiek stukje code die functie tegen om passwords te versleutelen.
Waarom is het trouwens niet veilig?

base64_encoding/decoding is gewoon door elke "jan lul" te decoden, simpelweg omdat het een standaard is die bedoelt is om enge tekens uit binaire bestanden te krijgen zodat het met een (asci) emailtje mee gestuurd kan worden.

[DRvDijk]

Ik zit ook al een tijdje na te denken over een site waar men kan reggen en hun instellingen van mail-servers op kunnen slaan en op die site dus hun POP-mail te checken.. Ik ben er nog niet aan begonnen, maar kij je (Carnifex) misschien een klein beetje vertellen hoe je zoiets zou gaan aanpakken? Met connectie naar de mail-server met name dus.. Gebruik je daar een of andere standaard functie van PHP voor, of heb je zelf het POP-protocol geimplementeerd?

[Verwijderd]

Ik kan zelf geen manier verzinnen om het zo te maken dat IK, de maker van het PHP spul, er zelfs niet achter kan komen wat de w8woorden van anderen zijn. Het probleem is dat ik overal toegang toe heb in de database omdat ik als root kan inloggen en precies weet wat er allemaal in de PHP documenten gebeurt (nouja probleem ).

okee maar dit ga je toch houden als je zoiets gaat maken, de beveiliging van jezelf is altijd te kraken. Maar het gaat er neem ik aan om om de gegevens voor de "buiten wereld" af te schermen?

Optie 1:
Per user een unieke key aanmaken, nadeel de key staat bij iedere user netjes in de database

//genereer key
$random = md5( uniqid ( rand() ) );
$key = substr( $random, 0,6);

Optie 2:
Key halen uit de username+password combi
(kan op willekeurige plaats in de string)
$key = substr( $username, 0,3);
$key .= substr( $password, 0,3);

$md5( $key );
$key = substr( $key, 0,6);

In dit geval het je een 6 cijferige key, die komt uit een combinatie van de username/pass met een md5 erover.
(en over het password zat al een md5)

Okee dit is natuurlijk niet 100% secure, kraak ftp+db en je hebt alle benodigde info om de $keys te maken.

maar dan kan je je toch gaan afvragen wat is de kans...

[DRvDijk]

Eehm.. password van de user is toch wel key genoeg? Die sla je neem ik aan als MD5-hash op.. Dan gebruik je dát om de passwords van de pop-boxen te 'coderen'. Volgens mij was dat idee al langsgekomen hier

[Verwijderd]

True

Maar Carnifex wil het super safe hebben.
Door deze extra codatie slag te maken sluit je de kans op een goeie "gok" uit.

[drm]

Er is behoorlijk wat encrypt/decrypt functionaliteit in mysql zelf, hoor.

check MySQL.com/doc/functions en doe ff text-zoeken op "ENCRYPT"
dan kom je er sowieso al 3 tegen. Misschien dat je d'r wat mee kan

[Verwijderd]

Er is behoorlijk wat encrypt/decrypt functionaliteit in mysql zelf, hoor.

[edit]
nevermind lezen is ook een vak

[Verwijderd]

Op donderdag 27 juni 2002 19:19 schreef int het volgende:

[..]

Of base64_encode()/base64_decode(), maar dit is zo makkelijk voor iemand te decoden...

base64 is niet bedoeld als beveiliging, maar om strings via bijvoorbeeld als get var te versturen zonder dat rare strings problemen opleveren. Het wordt ook gebruikt om attachments mee te 'coderen' voordat deze worden verstuurd...

[Carnifex]

Op maandag 01 juli 2002 02:25 schreef elviver het volgende:
Ik zit ook al een tijdje na te denken over een site waar men kan reggen en hun instellingen van mail-servers op kunnen slaan en op die site dus hun POP-mail te checken.. Ik ben er nog niet aan begonnen, maar kij je (Carnifex) misschien een klein beetje vertellen hoe je zoiets zou gaan aanpakken? Met connectie naar de mail-server met name dus.. Gebruik je daar een of andere standaard functie van PHP voor, of heb je zelf het POP-protocol geimplementeerd?

Nou, ik heb een beetje gekeken bij DevShed, daar heb je een goeie tutorial om een web-based mail client te maken. Ik pluk daar uit wat ik kan gebruiken of kijk er ff in als ik een probleempje heb. Beter(sneller) dan dat je alles uit de man. van PHP moet gaan opzoeken ofzo . Het is compleet met attatchments en de hele mikmak, dus vrij compleet. Maar we gaan natuurlijk niks copy-pasten, dat is lame.
Ik heb nu zelf een stukje gemaakt dat iig controleert of er post is op een adres en hoeveel berichten er zijn. Volgende stap is berichten te kunnen lezen. Dan het verzenden werkende te maken. Dan nog de attatchments en dan een beetje gaan 'tunen' en de lay-out perfectioneren . Tis best veel werk

http://www.devshed.com/Server_Side/PHP/PHPMail

Nog even over die 'key'. Ik stelde al voor om voor de key het login w8woord zelf te gebruiken. Het w8woord is in MD5 opgeslagen en ik wordt gecontroleerd door een soort van: "if password == md5($_POST['password'])"
Nou zou ik natuurlijk "$_SESSION['password'] = $_POST['password'];" kunnen doen zodat ik dat password overal op kan halen en als key kan gebruiken. Maar is dat veilig? Ik mag toch wel aannemen dat $_SESSION vars veilig zijn of niet? Als het kan, dan lijkt mij dit een veilige methode. Ik ben dus alleen onzeker over het meesturen aan de sessie van het ongecodeerde w8woord.

[DRvDijk]

Tsja, wat ik altijd doe is op élke pagina het session-wachtwoord controleren en alle rechten van de gebruiker ophalen.. In een TUser class ofzo.. Het password word in de sessie gezet inderdaad, maar telkens als er een PHP geladen wordt in de browser maar ik een TUser instantie aan, waarin dus gecontroleerd wordt of die pass wel klopt, en waar de rechten opgehaald worden.. Dat noem ik nog iets saver

[Carnifex]

Hmm, is dat niet een beetje overbodig en misschien wel onveiliger? Ik bedoel, je neemt de hele tijd zijn wachtwoord mee.. je kunt ook de hele tijd meenemen dat hij geldig is ingelogd. Dat lijkt mij minstens zo veilig. Nu kun je hooguit uitlezen of iemand ingelogd is, maar niet zijn wachtwoord.
gewoon een "$_SESSION['loged_in'] = true;" op de login pagina als de wachtwoord verificatie slaagt en dan op iedere volgend pagina "if($_SESSION['logged_in'] == true){......}else{echo 'not logged in';}" uitvoeren. Dat scheelt weer rekentijd voor het md5 algorithme (tenzij je het wachtwoord als md5 opslaat in je $_SESSION, maar dat kost waarschijnlijk weer meer geheugen) en een verbinding met je database.

[DRvDijk]

Tulak sla ik het password als MD5 op in de sessie! Wie kan dur allemaal wel niet bij die temp-dir waar die sessie-data opgeslagen kan worden?? Dá's onveilig!

Met $_SESSION["logged_in"] = true; is minder veilig.. Een echte h4x0r kan eenmaal bij de sessie-dir aangekomen gewoon de user-id in de sessie aanpassen en als admin ingelogd zijn..

Wat ik er net niet bijvertelde, maar wat ik dus doe, is 'fake-passwords' maken.. Random passwords die het cookie ingefrot worden, die telkens veranderen als er een PHP-peetsj aangeroepen wordt.. En ja, ik heb er zelfs een aparte tabel voor in de db Hiermee kan ik als admin zelfs mensen die 100 keer ingelogd blijven (ik werk met cookies, maar zelfde princiepe) allemaal er in een keer uitgooien, door de fake-logins db leeg te maken where id = userid

[TheRebell]

ik dacht dat di emanier van sessions (wat Carnifex zegt) toch redelijk veilig is. Als jij aan het begin van je page die variabelen ff netjes destroyed (zodat je ze niet kunt faken via de url) en ze daaran goed aanroept, dan is dat toch wel veilig
Ik doe het ook op die manier... Ik ben ook steeds bezig geweest met een goede manier van inlog-gegevens enzo maar je zult toch wel _iets_ moeten meegeven/opslaan.