Tijden veranderen
Bcrypt
Pagina: « vorige 1 2 3 4 5 volgende »
Een hacker komt toch wel bij je wachtwoorden...en hij komt er ook wel achter welke methodes je gebruikt...door iedere gebruiker een andere salt mee te geven voor kom je in ieder geval dat ie een dictionary attack gaat uitvoeren. immers voor ieder wachtwoord moet ie een andere dictionary genereren.
Sorry maar hoe komt een hacker achter je algoritme? Dat staat weggeschreven in je class of function php bestanden. Dan moet eerst een ftp account gehacked worden willen ze 'in' php bestanden kunnen kijken, nogmaals een vergeten escape is velen malen gevoeliger.
uiteraard is een hash op zich niet te reversen...maar wel alle andere acties die je er op los laat kun je reversen zodat je weer geldige hashe krijgt waarmee weer het test wachtwoord gematched kan worden...dit is een methode...en een FTP account kun je ook hacken hoor...skimmen...bugs in de FTP software...bugs in server beheer software zoals plesk panel...
Gewijzigd op 20/12/2012 12:24:16 door No One
Henze Berkheij op 20/12/2012 12:16:22:
@Chris..bijvoorbeeld reverse engineering...een hash hebben en het bijbehorende wachtwoord door zelf ook een account te hebben op de website...
Je weet toch niet hoe iemand zijn salt maakt zonder de broncode te hebben. Je kunt een salt maken door:
- een statische $salt aan te maken (of een niet gokbare variabelenaam)
- je kunt bepaalde gebruikersgegevens gebruiken.
- je kunt bepaalde 'stukken' gegevens gebruiken (bijvoorbeeld 3 letters voornaam etc)
En zo heb je er nog een paar, hoe ga jij reverse engineeren zonder broncodes te hebben?
1) Ik heb dus een andere salt voor elke gebruiker
2) Voor de hacker is het niet direct duidelijk welke gegevens van de gebruiker ik gebruik
3) Voor de hacker is het niet direct duidelijk welk algoritme ik gebruik
4) Voor de hacker is het niet direct duidelijk welke strings ik gebruik om van de gebruikers gegevens de salt te genereren.
De hacker zal dus de database met de juiste gegevens moeten hebben, de class waarin staat welke gegevens worden gebruikt, de class waarin het algoritme staat en de class waarin de strings worden ingegeven.
Als die hacker al dat heeft.... ok, dan houd het op.
( ik echo $password nadat die encrypted zou moeten zijn.)
Code (php)
Code (php)
Resultaat van de Echo:
Gewijzigd op 20/12/2012 12:27:02 door - Marco -
Gewijzigd op 20/12/2012 12:28:45 door No One
De manier van Erwin genereerd een unieke salt per gebruiker.
Henze Berkheij op 20/12/2012 12:30:18:
Ook zou je iedere keer bij een succesvolle inlog de gebruiker een nieuwe salt geven waardoor het nog onwaarschijnlijker wordt dat een hacker een wachtwoord kraakt...
Voor dat het zover is moet je wel een hele aantrekkelijk website hebben om er zoveel moeite voor te doen!
Nogmaals @Marco, ik zou gaan voor de oplossing die Erwin bied, meer dan veilig!
Henze Berkheij op 20/12/2012 12:32:47:
@chris, maar hij geeft toe dat er een einde zit, heeft iemand eenmaal toegang tot die gegevens, heeft men toegang tot alle wachtwoorden (die in een dictionary lijst voorkomen wel te verstaan) mijn mogelijkheid beperkt de mogelijkheid tot het vinden van wachtwoorden en dat is hoe dan ook veiliger
Als een hacker zover komt dat hij het php bestand heeft waar het algoritme instaat, dan heeft hij ook je DB gegevens inclusief host, username en password. Dus kan hij zo alle wachtwoorden wijzigen naar zijn wachtwoord. Dusja dan heb je zoveel moeite gedaan, en het is in 1 klap weg.
Ik neem aan dat je snapt dan 100% beveiligen onmogelijk is.
Toevoeging op 20/12/2012 12:38:20:
@Marco,
Wat krijg je te zien als je $_POST['password'] echo'd?
Henze Berkheij op 20/12/2012 12:32:47:
@chris, maar hij geeft toe dat er een einde zit, heeft iemand eenmaal toegang tot die gegevens, heeft men toegang tot alle wachtwoorden (die in een dictionary lijst voorkomen wel te verstaan) mijn mogelijkheid beperkt de mogelijkheid tot het vinden van wachtwoorden en dat is hoe dan ook veiliger
Henze, je begrijp dat einde verkeert. Mijn einde is precies hetzelfde als jouw einde. namelijk dat de hacker dan alle salts heeft (een andere per gebruiker) en dan IN THEORIE elk wachtwoord kan kraken. Alleen dan moet hij dat wel per gebruiker doen. In jouw geval heeft de hacker dat al door de database te kraken, bij mij heeft hij er nog drie andere bestanden voor nodig die lastiger zijn te vinden.
Daarom geef ik (en Erwin) ook al drie keer aan dat het opslaan van een salt in je db stukken gevoeliger is.
ik heb alleen meer moeite met de methode van Chris NVT die beweert dat een single salt in je code net zo veilig is. waar uiteindelijk maar 1 dictionary voor hoeft worden gegenereerd...
Jij zegt dat het niets toevoegt, maar dat ben ik dus zeker niet met je eens. Het voegt een extra laag eraan toe omdat de hacker nu verder moet komen dan alleen de database om die salt te verkrijgen.
Is het 100% veilig? Nee natuurlijk niet. Helaas is dat niet mogelijk. En als er nog een extra stap te zetten is om het veiliger te krijgen zal ik dat ook doen, alleen kan ik die op dit moment nog niet bedenken.
Ik sta dus wel altijd open voor nog verdere verbeteringen.
Henze Berkheij op 20/12/2012 12:56:28:
Het voegt eigenlijk vrij weinig toe... bovendien hebben bij gebruik van variabelen die niet veranderen hun eigen salt die in feite dus nooit veranderd ;).
ik heb alleen meer moeite met de methode van Chris NVT die beweert dat een single salt in je code net zo veilig is. waar uiteindelijk maar 1 dictionary voor hoeft worden gegenereerd...
ik heb alleen meer moeite met de methode van Chris NVT die beweert dat een single salt in je code net zo veilig is. waar uiteindelijk maar 1 dictionary voor hoeft worden gegenereerd...
Sorry maar ik 'beweer' nergens dat het 'net zo veilig' is! Ik geef aan dat voor kleinere site's die (door beginners) gemaakt worden een statische salt volstaat. Echter gaat mijn voorkeur uit naar de methode van Erwin als er gekozen wordt voor een unieke salt per gebruiker.
Pagina: « vorige 1 2 3 4 5 volgende »