[php] challenge/response icm salted password

[ajakkes]

Ik probeer een login script te maken wat werkt met een challenge/response in combinatie met een wachtwoord dat server-side gesalt is opgeslagen in de database.

Na een zoektocht kwam ik dit topic tegen:
http://gathering.tweakers.net/forum/list_messages/1407983

Alleen is hier volgens mij geen oplossing naar voren gekomen.

Als ik een challenge stuur (om te voorkomen dat het wachtwoord in plain text over het internet gaat) en hiermee een response krijg dat hash(wachtwoord+challenge) is.
En in mijn database het wachtwoord is opgeslagen als hash(wachtwoord+salt) kan ik dit onmogelijk vergelijken.

Nu probeer ik dit probleem op te lossen maar zie geen andere mogelijkheid dan de salt mee te sturen naar de client. Heeft iemand een idee om dit veiliger te doen.

[CyBeR]

Je hebt gelijk, wat je wilt kan per definitie niet zonder de salt mee te sturen. Challenge-Response-systemen hebben daarom altijd server-side uncrypted wachtwoorden of een equivalent daarvan (MS-CHAPv2 gebruikt een MD4 hash) nodig.

[Voutloos]

ajakkes schreef op maandag 16 augustus 2010 @ 17:05:
(om te voorkomen dat het wachtwoord in plain text over het internet gaat)

https \o/

[ajakkes]

https is geen optie.

Is het een idee om de salt te hashen of salt+challenge te hashen of schiet ik daar helemaal niks mee op?

Het is dus kiezen tussen twee kwaden?

[Fish]

ssl gebruiken is toch een optie ?
en vanaf 12 euro heb je al een echt certifikaat ook nog eens

[ Voor 48% gewijzigd door Fish op 16-08-2010 17:19 ]

[Spiked]

Digest authentication maakt gebruik van een nonce. Wellicht iets om je in te verdiepen?

[.oisyn]

Wat is er niet veilig aan het feit dat de salt publiekelijk bekend is. Of, om het om te draaien, waarom is het veiliger dat niemand de salt weet?

Spiked schreef op maandag 16 augustus 2010 @ 17:20:
Digest authentication maakt gebruik van een nonce. Wellicht iets om je in te verdiepen?

Het probleem daarmee is dat je de hash van het wachtwoord ongesalt in je database moet hebben staan, waardoor rainbow attacks mogelijk zijn voor mensen die de database weten te bemachtigen.

[ Voor 100% gewijzigd door .oisyn op 16-08-2010 17:23 ]

[Reptile209]

Spiked schreef op maandag 16 augustus 2010 @ 17:20:
Digest authentication maakt gebruik van een nonce. Wellicht iets om je in te verdiepen?

Och, als je Wikipedia: Salt (cryptography) leest, staat daar:

Salt is closely related to the concept of nonce.

Met het risico dat ik iets te veel last heb van klok & tepel: een nonce en salt zijn vergelijkbaar en worden op soortgelijke wijze toegepast. Ook de nonce moet immers over de lijn naar de client toe. Alleen een salt gebruik je misschien meermalen, een nonce is per definitie éénmalig.

.oisyn schreef op maandag 16 augustus 2010 @ 17:21:
Wat is er niet veilig aan het feit dat de salt publiekelijk bekend is. Of, om het om te draaien, waarom is het veiliger dat niemand de salt weet?
[...]

Zelfde wiki-pagina:

For best security, the salt value is kept secret. To determine a password from a stolen hash, an attacker cannot simply try common passwords (such as English language words or names). Rather, they must calculate the hashes of random characters (at least for the portion of the input they know is the salt), which is much slower.

[ Voor 33% gewijzigd door Reptile209 op 16-08-2010 17:27 ]

[Osiris]

Reptile209 schreef op maandag 16 augustus 2010 @ 17:26:
Zelfde wiki-pagina:

[...]

Uh-huh en dan pak je twee wachtwoorden uit die gejatte DB en staat er (na brute-forcing) tweemaal dezelfde sequence in.. Heeeyyy, zou dat misschien de salt zijn?

Dus so much for veiligheid bij brute-force attacks.

Ah, ik snap em, door de salt geheim te houden dwing je juist tot brute-forcen, jaja, op die manier. Maar gelukkig staan goeie passwords sowieso nooit in een dictionary

[ Voor 21% gewijzigd door Osiris op 16-08-2010 17:31 ]

[.oisyn]

Reptile209 schreef op maandag 16 augustus 2010 @ 17:26:
Zelfde wiki-pagina:

[...]

Security-by-obscurity.

Dictionary-attacks blijven voor afluisteraars altijd mogelijk, of je nou een salt gebruikt of niet. Maar door een user-specifieke salt te gebruiken voor de hash in de database is een raibowtable-attack iig ondoenlijk zodra de database in handen van iemand anders is. En áls dat gebeurt, dan is de hash meestal ook wel bekend bij de attacker.

[ Voor 51% gewijzigd door .oisyn op 16-08-2010 17:51 ]

[Verwijderd]

1 woord: hmac

Het idee is dat de challenge als salt wordt gebruikt en dat middels javascript aan de client-side een hash wordt gemaakt welke bestaat uit wachtwoord+challenge. Het echte wachtwoord wordt dus nooit in-the-clear verstuurt.

Ik heb hier een aantal jaar geleden een uitgebreid topic aan geweid mischien moet je dat eens doorlezen. Op pagina 2 haak ik in en onstaat een uitgebreide een constructiefe discussie. Goed leesvoer.
[PHP] Loginscript, is dit veilig?

[.oisyn]

3 woorden: lees de topic

Waar het de TS om te doen is is dat het wachtwoord of hash(wachtwoord) ook niet op de server opgeslagen is, maar wel hash(salt + wachtwoord)

[ Voor 11% gewijzigd door .oisyn op 16-08-2010 18:01 ]

[Verwijderd]

Was het idee van een salt niet om rainbow tabels onpraktische te maken en brute-forcen aftedwigen.

Volgensmij snapt de TS het idee van een salt niet helemaal. Gebruik in je database gewoon een per-user salt en een sterk hash-algoritme zoals SHA-1 en je dwingt een kwaadwillend persoon om per wachtwoord een compleet bruteforce traject te doorlopen.

En tja, als een salted database + HMAC challenge response systeem niet sterk genoeg is moet je naar eens naar RSA en PKI gaan kijken oftewel HTTPS in de browser wereld tenzij iemand een RSA javascript weet.

[.oisyn]

Verwijderd schreef op maandag 16 augustus 2010 @ 18:19:
Was het idee van een salt niet om rainbow tabels onpraktische te maken en brute-forcen aftedwigen.

Exact, daarom wil de TS een gesalte hash opslaan.

Volgensmij snapt de TS het idee van een salt niet helemaal

Ik heb zelf het idee dat de TS dat prima snapt, maar dat jij de topic niet helemaal begrijpt.

En tja, als een salted database + HMAC challenge response systeem niet sterk genoeg is moet je naar eens naar RSA en PKI gaan kijken oftewel HTTPS in de browser wereld tenzij iemand een RSA javascript weet.

Waar het om gaat is dat als je die twee (salt én challenge response) tegelijk wil toepassen, wat de TS dus wil, dan ontkom je er niet aan om de salt naar de client te sturen.

[Verwijderd]

Mischien snap ik het topic niet helemaal maar ziet de TS niet een probleem wat niet bestaat in praktische zin.

Een salt naar de client sturen kan perfect icm met HMAC en hoeft dus geen enkel probleem te zijn.

Een sniffer weet dan alleen de salt, challenge en de HMAC en niet het wachtwoord. Alleen bij het aanmelden moet het wachtwoord 1 malig in-the-clear naar de server waar deze wordt gehashed en ge-salt met een unieke salt. De salt en wachtwoord kunnen daarna gewoon in de database en mocht iemand de database in handen krijgen dat is die nog wel even bezig met brute-forcen tenzij er een zwakte in de SHA-1 hash functie bestaat.

Bij het aanmelden ziet de sniffer dus:
wachtwoord
In de database staat:
unieke salt + ge-salt en SHA-1 gehashed wachtwoord.
Bij het inloggen ziet de sniffer vanaf de server:
salt, unieke challenge
Bij het inloggen ziet de sniffer vanaf de client:
gebruikers-id, ge-salt wachtwoord dat is ge-HMACed.

Noch een sniffer, noch iemand die in de database bezit kan in een praktische tijd een wachtwoord vinden behalve dan tijdens het aanmelden waarneer het inderdaad helaas noodzakelijk is dat het wachtwoord in-the-clear wordt verstuurt of middels een ge-unsalted HMAC hash wat dan eigenlijk het wachtwoord wordt.

Ik zie geen probleem met deze vorm van beveiliging en alleen het overstappen op publieke/private RSA sleutels zijn in praktische zin nog veiliger todat Quantum computers een realiteit worden dan.

De sterke van het hele systeem hangt af van de sterkte van de HASH algoritme omdat zelfs als je de salt weet je nog steeds moet gaan brute-forcen iets wat met SHA-1 iets van 279 jaar duurt en dat is per wachtwoord want elke gebruiker heeft zijn eigen unieke salt dus rainbow tabels zijn compleet onpraktisch.

[Cartman!]

Tja, zonder ssl is het een beetje kiezen of delen... Ik heb destijds voor een soortgelijk systeem volgens mij gekozen voor een unieke salt per user. Bij het aanmelden wordt dan de salt opgehaald adhv. de username met een random token (challenge) waarbij met alles de response wordt berekend. Op die manier gaat je password nooit plain over de lijn.

ik gebruik meestal SHA256 of Whirlpool voor het hashen overigens.

[ Voor 8% gewijzigd door Cartman! op 16-08-2010 22:02 ]

[Soultaker]

Als je een salt en challenge naar de client stuurt, dan kunnen zowel client als server toch prima hash(hash(wachtwoord+salt)+challenge) berekenen? Probleem opgelost, of mis ik wat?

[ajakkes]

Volgens mij heeft soultaker de beste oplossing. Om de theorie eenvoudig te houden: gebruiker heeft name: a en ww: 1
De meeste gebruikers gebruiken vaak hetzelfde ww.
Als de gebruiker 1 over het net stuurt en dit wordt gesniffed kan de hackers als deze gebruiker op mijn site en op die van anderen.
Als ik een site eigen salt stuur moet de hackers voor mijn site een rainbow table maken om achter het ww te komen. Hierna salt ik het ww met user eigen salt en sla salt en dubbel salted ww op in database.
Voorkomen dat sniffer de hash opstuurt en als gebruiker inlogged gaat toch niet.

[ajakkes]

aanmeldform + sitesalt naar gebruiker
hash(sitesalt + ww) naar server
hash(hash(sitesalt + ww)+usersalt) in database

Ik kan geen manier bedenken waarbij een challenge hier extra veiligheid aan toevoegd.
Misschien heb ik het nonce of hmac verhaal niet helemaal begrepen.

Of ik moet na het opvragen van de username in een volgend form het ww opvragen en dat wil ik ook niet.

Het voordeel dit systeem is dat er een aparte rainbow table nodig is voor elke site en een aparte rainbow table voor elke user en het eventueel gebruik van onveilig ww op mijn site geen gevolgen heeft voor het gebruik van dat ww op andere sites.

Iemand anders nog ideeën?

[Flard]

Volgens mij is het nadeel van deze methode dat je nog steeds een replay attack kunt uitvoeren.
Een kwaadwillende hacker die jou gesniffed heeft kan exact dezelfde gegevens (sitesalt + ww) naar de server sturen om in te loggen, dus hoeft jouw wachtwoord niet te kennen.

[Cartman!]

Nee, want die challenge is gebonden aan jouw sessie. Een andere user (met een andere sessie) krijgt een andere challenge aangeboden waardoor de response niet overeenkomt en je login dus faalt.

[ajakkes]

Inderdaad Flard. Daar worstel ik ook mee. In mijn laatste post heb ik het niet meer over een Challenge. Ik heb nog geen idee hoe ik de Challenge kan combineren met een Salted WW in mijn database en hiermee de beveiliging verhoog.

Zoals ik het nu omschrijf heb ik puur het WW zelf beveiligd. Niet de mogelijkheid dat de hacker de hash onderschept en hiermee op mijn site inlogged.

[Cartman!]

De toevoeging van de challenge/nonce is dus de randomheid voor iedere login die een user doet waardoor het simpelweg herhalen van een username & response je niet zal inloggen.

[ajakkes]

Maar hoe implementeer ik die?

ik heb:
u -> wanna login -> s
u <- salt1 <- s
u -> name -> s
u -> hash(salt1+ww) -> s
s -> name -> d
s <- salt2 <- d
s -> hash(hash(salt1+ww)+salt2) -> d
s <- okey <- d
u <- private page <- s

u = user
s = site/server
d = database
salt1 = site uniek
salt2 = user uniek

Hier moet ik dus een challenge aan toevoeg die request uniek is, maar hoe?

edit: u -> wanna login -> s toegevoegd

[ Voor 8% gewijzigd door ajakkes op 17-08-2010 11:08 . Reden: verduidelijking ]

[Cartman!]

Bij het teruggeven van je salt aan de client stuur je een challenge mee die je serverside ook opslaat. Clientside maak je de response: hash(challenge + hash(salt + password)) en dat stuur je als je challenge op. Een serverside salt gebruiken bovenop je usersalt is imo een beetje zinloos want je salt is toch al uniek per user.

Let ook op dat als je post je dus je password veld leegmaakt, heb wel vaker pagina's gezien waarbij keurig een response wordt berekend maar waarbij het plain password nog steeds werd meegestuurd

[.oisyn]

ajakkes schreef op dinsdag 17 augustus 2010 @ 08:03:
Volgens mij heeft soultaker de beste oplossing.

Niet om het een of ander, maar dat riep ik in het begin toch al? (of eigenlijk zei je het zelf al in de topicstart, ik gaf alleen aan dat dat best kan)

Overigens zie ik ook geen reden voor een site-salt. Compleet overbodig als je al een user-salt hebt.

Het nadeel hiervan is echter wel dat je een extra round-trip nodig hebt. De site kan de usersalt immers pas opsturen als hij weet welke user er wilt inloggen. Een mogelijkheid is om de username als usersalt te gebruiken, alleen dan moet je wel bedenken dat een username niet zomaar gewijzigd kan worden.

Hou er ook rekening mee dat je bij het aanmaken van een account of het wijzigen van het wachtwoord ook niet wilt dat het ww plain text over het net gaat. Je kunt de client dan wel de hash(ww + salt) op laten sturen die jij direct in de database opslaat, maar zodra dit afgeluisterd wordt heeft de afluisteraar alsnog genoeg informatie om in te kunnen loggen. HTTPS is hier feitelijk de enige oplossing.

[ Voor 71% gewijzigd door .oisyn op 17-08-2010 11:55 ]

[jbdeiman]

ajakkes schreef op dinsdag 17 augustus 2010 @ 08:03:
Volgens mij heeft soultaker de beste oplossing. Om de theorie eenvoudig te houden: gebruiker heeft name: a en ww: 1
De meeste gebruikers gebruiken vaak hetzelfde ww.
Als de gebruiker 1 over het net stuurt en dit wordt gesniffed kan de hackers als deze gebruiker op mijn site en op die van anderen.
Als ik een site eigen salt stuur moet de hackers voor mijn site een rainbow table maken om achter het ww te komen. Hierna salt ik het ww met user eigen salt en sla salt en dubbel salted ww op in database.
Voorkomen dat sniffer de hash opstuurt en als gebruiker inlogged gaat toch niet.

Hoe had je de salt in gedachten? Specifieke potitionering van de salt ergens in het ww? Of wou je hem eerst salten en dan nog een encodering eroverheen halen?

Ik heb zelf ook wel met dit vraagstuk lopen worstelen, waar ik op uit kwam is wel vrij ingewikkeld, maar miss leuk om eens te proberen. (ben nooit aan het maken toegekomen):

Je stuurt een bepaalde salt (letters/ cijfers door elkaar) mee. Elk van deze tekens staat voor een bepaalde positie, heb je meerdere tekens op dezelfde positie, dan worden deze achter elkaar geplaatst.

Met deze salt pas je het ww aan, voordat het wordt verzonden. Het leuke is dat je op die manier elke keer een ander gesalt wachtwoord krijgt, en dat die elke keer anders lijkt. Ook doordat de posities van tekens wisselen en tekens die in je password staan meermaals kunnen voorkomen (ook steeds op een andere positie) is dit ook bijna niet meer te achterhalen voor een man in the middle.

Alleen met het algoritme (js, op zich te doen) en de verstuurde salt kan je iets achterhalen, maar ook dan geldt dat dit al lastiger is om te doen.
En omdat de salt steeds anders is, blijft het lastig en is het ook lastig om als die gebruiker in te loggen, zeker in combinatie met een challenge.

[ajakkes]

jbdeiman: met salten bedoel ik hash(salt+ww) oftewel md5/sha1(salt+ww).
waar jij het over hebt is encryptie(salt+ww) o.i.d. wat je serversided weer decrypt. Dit is met hash niet mogelijk.

.oisyn: Ja, daar heb je gelijk in. Alleen heb ik het vermoeden dat het wel degelijk beter kan, weet alleen nog niet hoe.

Cartman!:
u -> wanna login -> s
u <- salt1 en challenge en session <- s
s -> session en challenge -> d
u -> name -> s
u -> hash(hash(ww+salt1)+challenge) en session -> s
u -> hash(ww+salt1) -> s
s -> name -> d
s <- salt2 <- d
s -> hash(hash(ww+salt1)+salt2) -> d
s <- ww okey <- d
s -> session -> d
s <- challenge <- d
s -> hash(hash(ww+salt1)+challenge) = hash(hash(ww+salt1)+challenge)
u <- private page <- s

Waarbij controle van challenge en ww omgedraaid kunnen worden natuurlijk. Dit zou beter moeten zijn?

[ Voor 2% gewijzigd door ajakkes op 17-08-2010 12:36 . Reden: edit: foutje: database kan hash(hash(ww+salt1)+challenge) niet controleren. Moet site/server zelf doen. ]

[Cartman!]

Je denkt echt veel te complex, laat dat idee van meerdere salts toch vallen

Hier komt t op neer:
C: user voert username+password in en submit form
C: vang submit af en stuur username via xhr naar server
S: zoek user op en geef salt + challenge terug, sla challenge ook serverside op
C: maak response: hash(hash(salt+pw)+challenge)
C: submit username+response
S: zoek user op, maak response: hash(db password+challenge)
S: vergelijk challenges

Natuurlijk zijn er nog wel meer dingen waar je aan moet denken (bijv. hoe je om gaat met usernames die je niet in je db hebt staan bij het vragen van een salt etc).

[ajakkes]

Ik heb weinig ervaring met javascript. Vandaar dat ik nog niet gedacht had aan xhr.

Als ik het op mijn manier uitschrijf komt het neer op het volgende:

u -> wanna login -> s
u -> name -> s
s -> name en challenge-> d
s <- salt2 <- d
u <- salt2 en challenge <- s
u -> hash(hash(ww+salt2)+challenge) en name -> s
s -> name -> d
s <- challenge <- d
s <- hash(ww+salt2) <- d
s -> hash(hash(ww+salt2)+challenge) = hash(hash(salt2+ww)+challenge)
u <- private page <- s

En dan zou je eigenlijk een fakename | fakesalt2 tabel moeten maken voor het antwoorden op foute names

Voor de consistentie heb ik de user eigen salt nog steeds salt2 genoemd. Er is in dit geval geen salt1 meer.

Tnx. Cartman! voor het meedenken.

[Cartman!]

ajakkes schreef op dinsdag 17 augustus 2010 @ 14:53:
En dan zou je eigenlijk een fakename | fakesalt2 tabel moeten maken voor het antwoorden op foute names

Dat kan, of je gebruikt een hashmethode op de username (evt. een vaste transformatie erop toepassen) zodat je ook altijd dezelfde salt returned voor niet-bestaande usernames. Dat scheelt je weer werk voor het opslaan van gegevens.

[ajakkes]

Ook na 3 keer lezen zie ik niet wat je bedoelt.

De hacker zal usernames gaan sturen naar de database om te kijken of hij bestaat.
Hij krijgt een salt terug.
Een dag later stuurt hij dezelfde username en kijkt of hij een andere salt terug krijgt.
Als de salt gelijk blijft bestaat de username. Dit is wat de hacker wil bereiken en de dev wil voorkomen.

Ahh. maar als ik bij niet bestaande usernames de salt baseer op de username hoef ik hem niet op te slaan. En dit zou ik ook kunnen doen bij wel bestaande usernames?

Als ik de salt baseer op de username hoef ik hem ook niet tussentijds op te halen, toch?

Maar heb ik wel per user een verschillende salt.

[Reptile209]

Maarrrr... als de salt van de username met een algorithme te berekenen is, is dat toch geen extra bescherming? Security-through-obscurity zolang je algo niet op straat ligt. Deze salt zou dus random moeten zijn, en moet (dus) ook in de DB worden opgeslagen.
Meteen een mooie 'DoS': een enorme berg fake usernames naar de server sturen, waarvan de server een salt moet berekenen en opslaan. Kan je wachten op problemen met je DB (schijfruimte) of server (processorkracht).

[.oisyn]

Reptile209 schreef op woensdag 18 augustus 2010 @ 12:06:
Maarrrr... als de salt van de username met een algorithme te berekenen is, is dat toch geen extra bescherming?

Het beschermt tegen rainbow attacks voor als de database gehackt is. Tegen eavesdropping beschermt een salt sowieso niet, en als een derde toegang heeft tot de data dan weet ie de salts ook.

[ Voor 13% gewijzigd door .oisyn op 18-08-2010 12:25 ]

[ajakkes]

Ik ga ervan uit dat de source bekend is.

Om die reden heeft het geen zin om een salt van een bestaande username anders te berekenen als de salt van een niet bestaande username. Dus of ik sla de salt van niet bestaande usernames op of ik sla de salts van bestaande usernames niet op.

Verder beveilig het echte wachtwoord tegen eavesdropping door er een salt overheen te gooien.

Daarbij bescherm ik als er toegang tot de database is dat alle wachtwoorden in een keer op staat liggen door voor iedere user een andere salt te gebruiken. Voor iedere user is er dan een aparte rainbow table nodig.

Dan komt de laatste stap. Een challenge die ik meestuur naar de gebruiker en opsla in de database. Hierdoor is het niet mogelijk dezelfde hash twee keer op te sturen. Immers als de password samen met de challenge aankomt bij de server wordt het vergeleken met de opgeslagen password. Als dit overeenkomt wordt de challenge verwijderd.

Zie ik nu nog dingen over het hoofd?

[.oisyn]

ajakkes schreef op woensdag 18 augustus 2010 @ 12:32:
Verder beveilig het echte wachtwoord tegen eavesdropping door er een salt overheen te gooien.

Nee, daar is de challenge weer voor

[ajakkes]

Huh, oh ja,

De salt moet ik client-side toepassen omdat ik anders de challenge er niet overheen kan gooien. Zo was het.

dus
hash(hash(ww+hash(username))+challenge)

waarbij ik de "salt" hash(username)+hash(username) om de salt wat lengte te geven.

dan krijg je dus bij een simpele user:
in de database:
hash(1+hash(a)+hash(a))
over het net:
hash(hash(1+hash(a)+hash(a))+challenge)

[ajakkes]

JavaScript:

document.getElementById( 'userhash' ).value = hex_md5( document.getElementById( 'username' ).value + hex_md5( document.getElementById( 'username' ).value ));

is zeker niet hetzelfde als

PHP:

$Userhash = (md5($Username).md5($Username));

De id username is gelijk aan variabele $Username

edit:
oplossing gevonden:

JavaScript:

document.getElementById( 'userhash' ).value = (hex_md5( document.getElementById( 'username' ).value) + (hex_md5( document.getElementById( 'username' ).value )));

[ Voor 24% gewijzigd door ajakkes op 18-08-2010 13:43 . Reden: Oplossing gevonden ]

[Verwijderd]

Volgensmij ga je er met dit protocol nauwelijks op vooruit qua veiligheid.
In de database staat hash(ww + salt), en de response is hash( hash(ww + salt) + challenge).
Zoek de verschillen. Het wachtwoord is nu niet meer te achterhalen, daar heb je gelijk in. Maar het wachtwoord is helemaal niet meer nodig om in te kunnen loggen, daarvoor heb je hash(ww + salt) voor nodig. En die staat letterlijk in de database. Gevolg is dus dat als iemand jouw database leegtrekt, hij de orginele wachtwoorden niet meer kan achterhalen, maar wel als iedere willekeurige gebruiker in kan loggen.

Wat je nu hebt gedaan is de mogelijkheid van password sniffen in ruilen tegen het risico van een attacker die je db leegtrekt.

Als je echt niet aan de SSL wil, kun je Diffie-Hellman of RSA implementeren, maar in feite doe je dan een soort van poormans SSL over HTTP.

[Cartman!]

Volgens mij begreep je m'n verhaal niet helemaal over de salt van niet bestaande users. Voor een bestaande user is je salt altijd random en in principe nergens op gebaseerd (behalve wellicht de tijd of /dev/(u)random oid). Maar als iemand wil checken of een username bestaat dan kun je dus 'gewoon' zoiets returnen:

PHP:

$userRow = $user->findByUsername($username);
if($userRow == null) {
    $username = strtr($username, 'abc', 'bac'); // etc
    return substr(sha1($username), 10, 8); // of hoe lang je salt dan ook is
}
return $userRow->salt;

Zo is de salt die je returned voor een niet-bestaande username altijd hetzelfde en zal de aanvaller nooit verschil kunnen maken tussen wel of niet bestaande users.

@anton_89: naar mijn idee doet dat er totaal niet toe. Iemand die al toegang heeft tot je database zal op dat moment waarschijnlijk weinig moeite meer doen om op die manier in te kunnen loggen, je data is toch al bereikt. Het belangrijke in dit verhaal is dat je passwords niet op straat liggen en ook niet te reversen zijn met rainbowtables.

hash(hash(ww+hash(username))+challenge)

nee nee nee, waar haal je nu die 3e keer hashen ineens weer vandaan? In je db sla je bij een user de salt op en als password hash(salt+password). Makkelijker kunnen we t echt niet maken voor je volgens mij En wat je nu met de hashes van de usernames aan het vogelen bent vat ik ook niet helemaal

[ Voor 33% gewijzigd door Cartman! op 18-08-2010 14:12 . Reden: code-tags :P ]

[ajakkes]

Omdat ik enorm aan het vogelen ben geweest om de username tussentijds uit de database te trekken, maar ik daarvoor me iets meer moet verdiepen in javascript.

en daarbij

Quote van mij enkele berichten geleden:"Om die reden heeft het geen zin om een salt van een bestaande username anders te berekenen als de salt van een niet bestaande username. Dus of ik sla de salt van niet bestaande usernames op of ik sla de salts van bestaande usernames niet op."

Maar daarvoor heb ik nog steeds een user based salt nodig. Deze creëer ik door hash(username)
Hiervoor hef ik maar een klein beetje veiligheid op.

Wat maakt random salt in database opslaan en verzenden veiliger dan hash(username) gebruiken?

Zoals ik al aangaf heb ik op drie punten beveiligd en daar heb ik volgens mij deze 3 hashes voor nodig.

[ajakkes]

@anton:

Als iemand de database met wachtwoorden leeg trekt kan hij inderdaad als iedere user inloggen. Ken jij sites waar dat niet zo is?

De wachtwoorden in de database beschermen doe je volgens mij zodat als de database leeg getrokken wordt de gebruikers niet op 25 andere sites hun wachtwoorden moeten veranderen, op jou site liggen alle gegevens toch al op straat.

[.oisyn]

Verwijderd schreef op woensdag 18 augustus 2010 @ 14:04:
In de database staat hash(ww + salt), en de response is hash( hash(ww + salt) + challenge).
Zoek de verschillen.

Het verschil is dat een afluisteraar niet op een later moment kan inloggen.

Maar het wachtwoord is helemaal niet meer nodig om in te kunnen loggen, daarvoor heb je hash(ww + salt) voor nodig. En die staat letterlijk in de database. Gevolg is dus dat als iemand jouw database leegtrekt, hij de orginele wachtwoorden niet meer kan achterhalen, maar wel als iedere willekeurige gebruiker in kan loggen.

No shit sherlock . Als je database compromized is, dan heb je wel grotere problemen dan mensen die kunnen inloggen onder een andere naam. De salt is ervoor om te zorgen dat de originele wachtwoorden van de gebruiker in zo'n geval alsnog veilig zijn, niet om ervoor te zorgen dat iemand niet kan inloggen als hij over de database beschikt.

Wat je nu hebt gedaan is de mogelijkheid van password sniffen in ruilen tegen het risico van een attacker die je db leegtrekt.

Er is helemaal niets ingeruild. En als je dat toch wel denkt, dan stel ik voor dat jij een systeem presenteert waarbij het onmogelijk is voor een attacker om in te loggen zodra hij de database in handen heeft (zonder gebruik te maken van public key cryptography).

[Dracoo]

.oisyn schreef op woensdag 18 augustus 2010 @ 14:39:
[...]
Er is helemaal niets ingeruild. En als je dat toch wel denkt, dan stel ik voor dat jij een systeem presenteert waarbij het onmogelijk is voor een attacker om in te loggen zodra hij de database in handen heeft.

Een oplossing hiervoor zou zijn dat je het door de site gehashte wachtwoord nogmaals hasht met een server salt voordat je het met de hash uit het db gaat vergelijken (db-hash natuurlijk ook gehasht met deze salt). Deze server-salt sla je dus niet in het database op, maar bv in een file.

Oke toegegeven: Het is maar de vraag wat je hiermee wint. Indien een 'hacker' het db heeft gecompromised dan krijgt ie in het veel gevallen ook wel voor elkaar deze file van je filesystem te lezen. En zoals gezegd: je data ligt al op straat..

[Verwijderd]

.oisyn schreef op woensdag 18 augustus 2010 @ 14:39:
Er is helemaal niets ingeruild. En als je dat toch wel denkt, dan stel ik voor dat jij een systeem presenteert waarbij het onmogelijk is voor een attacker om in te loggen zodra hij de database in handen heeft (zonder gebruik te maken van public key cryptography).

Door het aloude systeem van een een wachtwoord plaintext over het internet te sturen daarvan een salted hash in de db hebben staan. Als de attacker dan een hash uit de db vist kan hij niks. Hij heeft immers de plaintext nodig.

De zwakte van dit systeem is echter dat je het wachtwoord kun sniffen. Dat is wat bij het protocol van ajakkes weer niet kan. En dat is wat je omruilt

[Cartman!]

.oisyn schreef op woensdag 18 augustus 2010 @ 14:39:
[...]

Niet om het een of ander, maar dat riep ik net toch al?

Dracoo: waardeloos dus want je kunt net zo goed de sessie-tabel opzoeken en van jouw sessie het userid veranderen, dan omzeil je het hele login-gebeuren al natuurlijk. Echt waar, als iemand je db in kan dan heeft t sowieso al weinig zin om dat invloed te laten hebben op de manier van inloggen.

@anton_89: volgens mij moet je het topic iets beter gaan lezen want volgens mij want .oisyn heeft het bij het rechte eind.

[ Voor 11% gewijzigd door Cartman! op 18-08-2010 15:06 ]

[.oisyn]

@Cartman!: wtf, jouw post heb ik dus echt totaal niet gezien

@anton_89: ah ja idd, daar heb je gelijk in. In de huidige situatie wordt idd wat ingeruild. Maar dat kun je op zich nog wel voorkomen door beide systemen te combineren. In de database sla je dan bijv. zowel hash(ww+salt1) als hash(hash(ww+salt2)+salt2) op. Voor de eerste doe je een challenge check op hash(hash(ww+salt1) + challenge), voor de tweede check je of de opgestuurde hash(ww+salt2) overeen komt met de waarde in de database (dus hash(hash(ww+salt2)+salt2)).

Nu kun je niet inloggen door de sniffen, en ook niet door de db te bemachten. Maar als je allebei doet kan het weer wel. De vraag is of het de moeite überhaupt waard is.

[ Voor 169% gewijzigd door .oisyn op 18-08-2010 15:21 ]

[Dracoo]

Cartman! schreef op woensdag 18 augustus 2010 @ 15:03:
Dracoo: waardeloos dus want je kunt net zo goed de sessie-tabel opzoeken en van jouw sessie het userid veranderen, dan omzeil je het hele login-gebeuren al natuurlijk. Echt waar, als iemand je db in kan dan heeft t sowieso al weinig zin om dat invloed te laten hebben op de manier van inloggen.

Haha.. ja das waar. Als je persé wilt inloggen (met andermans credentials) is dat een makkelijkere optie als de database attacken. Maar daar ging het nu even niet om. Het punt was juist dat als je database al op straat ligt, hoe voorkom je dan dat iemand met een hash in kan loggen. En dat kan wel. Of het nut heeft? Nee!

[Cartman!]

Dat kan dus niet want je login is beveiligd met een challenge

@.oisyn

[.oisyn]

Dat kan dus wel. Als je hash(ww + salt) weet dan kun je zelf elke challenge forgen.

[Verwijderd]

@.oisyn: volgensmij is het opslaan van hash(hash(ww+salt1)+salt2) ook genoeg. Precies wat je voor je edit zei dus

[.oisyn]

Nee, want dan kun je de challenge niet meer doen (want daarvoor moet de server hash(ww+salt1) weten), daarom had ik dat weggeedit

[ Voor 24% gewijzigd door .oisyn op 18-08-2010 15:27 ]

[mace]

Trouwens, wat wil je precies beveiligen. Staat er gevoelige info op die site? Ook al weet je zonder SSL de authenticatie waterdicht te maken (wat IMHO nooit helemaal lukt) kun je alsnog de http sessie sniffen en zodoende aan de gegevens komen die je wilt hebben. Hoef je niet in te loggen maar dan laat je het de user zelf gewoon doen.

Waarom is SSL geen optie eigenlijk?

[ Voor 5% gewijzigd door mace op 18-08-2010 15:33 ]

[Verwijderd]

@.oisyn: Oops, je hebt gelijk. Ik let ook even niet op

[ Voor 8% gewijzigd door Verwijderd op 18-08-2010 15:34 ]

[ajakkes]

@anton

Meestal zijn de userbased salts opgeslagen in de database
Je zou er voor kunnen kiezen een sitebased salt te gebruiken, dan zijn alle salts hetzelfde
Of je slaat zoals Dracoo voorstelt voor iedere user de salt op in een file

Maar dan stap je eigenlijk al over het feit dat 90% van de data opgeslagen is in de database. Welke data bescherm je dan nog die wel te benaderen is na login? Of bescherm je het feit dat de hacker zich uit gaat geven als andere gebruiker?

Nee, ik denk niet dat ik mijn site ga beschermen tegen toegang nadat de hacker de database heeft leeggetrokken.

Volgens mij blijf ik toch bij:
hash(hash(hash(username)+ww)+challenge)
Niet moeilijk te implementeren en toch veilig. Waarbij naar mijn mening op de site die ik wil maken het beschermen van het ww voorop staat.

edit:
@Mace: SSL is geen optie omdat de site laagdrempelig op ieder hostingpakket moet kunnen draaien. Ik verwacht niet dat er echt gevoelige data op komt staan.
De methode moet dus goedkoop en veilig zijn. De huidige methode kost niks en is eenvoudig te implementeren. Ik kan dus iedereen aanraden deze methode te gebruiken. Hij is veiliger dan de meeste inlog scripts die ik tegenkom.

Hij is echter wel afhankelijk van javascript. Zonder javascript valt de beveiliging tegen plaintext ww versturen en het challenge/response systeem weg. Maar dat is een gebruikerskeuze. Ik heb mijn best gedaan.

[ Voor 27% gewijzigd door ajakkes op 18-08-2010 15:47 . Reden: Reactie op Mace ]

[Cartman!]

.oisyn schreef op woensdag 18 augustus 2010 @ 15:23:
Dat kan dus wel. Als je hash(ww + salt) weet dan kun je zelf elke challenge forgen.

Ja ok, maar we gaan er dus niet vanuit dat iemand toegang heeft tot je DB. Dan ben je nogal een domme 'hacker' als je op die manier gaat inloggen als een ander natuurlijk zoals ik eerder al aanhaalde.

@ajakkes:
Als je username als je salt gebruikt mag een user dus nooit z'n naam wijzigen zonder zijn password mee te wijzigen. Lijkt me niet heel ideaal, daar al over nagedacht?

[Dracoo]

@ ajakkes: Ik bedoelde één enkele server-salt. Maar de optie die .oisyn geeft is beter/mooier

[.oisyn]

Cartman! schreef op woensdag 18 augustus 2010 @ 15:44:
[...]

Ja ok, maar we gaan er dus niet vanuit dat iemand toegang heeft tot je DB. Dan ben je nogal een domme 'hacker' als je op die manier gaat inloggen als een ander natuurlijk zoals ik eerder al aanhaalde.

Daar ben ik het verder ook helemaal mee eens, dus ik zou zelf de moeite niet doen om dat te beschermen. Desalniettemin wilde ik even aangeven dat het weldegelijk zo is dat als een hacker de opgeslagen hash weet dat hij dan gewoon in kan loggen.

[ajakkes]

Inderdaad Cartman! als je de username wil veranderen zal je nogmaals je wachtwoord moeten ingeven, dit wordt op meer sites gevraagd, dus zie daar geen probleem in.
Ook is de username hoofdletter-gevoelig geworden (op dit moment). Hier heb ik zelf een hekel aan dus wil nog wel een strtolower functie inbouwen voor de hash(strtolower(username)). Zal even zoeken naar de javascript functie.

[mace]

Nee doe dat nou niet, dan verlies je een orde van grootte aan complexiteit van je wachtwoord.

[.oisyn]

Onzin, het gaat hier om de username, niet om het wachtwoord zelf

[ Voor 32% gewijzigd door .oisyn op 18-08-2010 16:05 ]

[mace]

Excuus, daar heb ik overheen gelezen.

[ajakkes]

@mace

hehe, ik bespeur enige mate van sarcasme

Ik heb het werkend. Alleen stuur ik nu de challenge nog heen en weer via $_SESSION. Moet ik nog even in de database opslaan.

En hier en daar nog wat code opschonen, $_POST beveiligen e.d.

Iederen bedankt voor het meedenken.
Hoop dat anderen er ook iets aan hebben gehad.

[ViNyL]

Is het niet zo dat je met https iig al voorkomt dat het password plaintext over de lijn gaat en dus praktisch niet gesniffed kan worden?

Kijk anders eens naar: http://sourceforge.net/projects/useratuh/

[ Voor 20% gewijzigd door ViNyL op 18-08-2010 16:21 ]

[CodeCaster]

ViNyL schreef op woensdag 18 augustus 2010 @ 16:16:
Is het niet zo dat je met https iig al voorkomt dat het password plaintext over de lijn gaat en dus praktisch niet gesniffed kan worden?

Is het niet zo dat je een topic moet doorlezen voordat je antwoordt?

[Verwijderd]

@ajakkes: het maakt niet uit of je salt in de db staat of in een file. Het ging erom dat hash(ww+salt) in de db stond.

@.oisyn / Cartman!: ik geef toe dat het wat ver gezocht is, maar niet geheel onmogelijk. Het is IMHO een zwakte in het protocol. Een poosje geleden kwam ik een demonstratie tegen waar een site vatbaar was voor sqlinjectie, maar het enige wat je terug kreeg was wel of niet een pagina. Toch konden ze daarmee een username en wachtwoord uit de db vissen.(kan het betreffende filmpje niet meer terugvinden ) Om maar even aan te geven dat een attacker niet altijd volledige controle heeft over een database om er toch iets uit te kunnen halen

En zoals gezegt, security is een kosten/baten afweging.

Overigens ben ik benieuwd waarom SSL geen optie is?

[ViNyL]

CodeCaster schreef op woensdag 18 augustus 2010 @ 16:18:
[...]

Is het niet zo dat je een topic moet doorlezen voordat je antwoordt?

Slechte dag vandaag? Als je 2 tellen had gewacht had er ook nog een link bij gestaan...

[ Voor 13% gewijzigd door ViNyL op 18-08-2010 16:25 ]

[CodeCaster]

ViNyL schreef op woensdag 18 augustus 2010 @ 16:22:
[...]


Slechte dag vandaag?

Niet alleen vandaag.

[Cartman!]

Verwijderd schreef op woensdag 18 augustus 2010 @ 16:18:
@.oisyn / Cartman!: ik geef toe dat het wat ver gezocht is, maar niet geheel onmogelijk. Het is IMHO een zwakte in het protocol. Een poosje geleden kwam ik een demonstratie tegen waar een site vatbaar was voor sqlinjectie, maar het enige wat je terug kreeg was wel of niet een pagina. Toch konden ze daarmee een username en wachtwoord uit de db vissen.(kan het betreffende filmpje niet meer terugvinden ) Om maar even aan te geven dat een attacker niet altijd volledige controle heeft over een database om er toch iets uit te kunnen halen

Dan moet je wel eerst vatbaar zijn voor SQL-injectie. Als je overal en altijd je inputs escaped voordat je er een query mee uitvoert dan is dat niet meer mogelijk dus.

[mace]

@ajakkes Waarom wil je trouwens niet vertellen waarom SSL geen optie is?

@anton: Dat was waarschijnlijk de Oracle padding exploit.

[.oisyn]

Het nadeel van SSL is dat virtual hosts zo goed als onmogelijk zijn als je ook nog een geldig certificate wilt hebben

[mace]

.oisyn schreef op woensdag 18 augustus 2010 @ 16:52:
Het nadeel van SSL is dat virtual hosts zo goed als onmogelijk zijn als je ook nog een geldig certificate wilt hebben

Subject Alternative Names extensie werkt anders behoorlijk goed.

[ajakkes]

@anton_89

Als de hacker toegang heeft tot de gebruikersnaam/wachwoord in de database heeft hij ook toegang tot de salt in die database. (Kans is volgens mij heel klein dat het niet zo is).

Om de hacker geen toegang tot de site te geven als hij toegang heeft tot de username/wachtwoord zal je dus de salt moeten opslaan in je filesystem. Als je niet wil dat het wachtwoord op straat ligt moet je hash(wachtwoord+salt) opslaan in je database.

Het is inderdaad mogelijk om hash(hash(ww+salt)+challenge) toe te passen waarbij de salt opslaat in het filesystem. Echter dan moet je de salt (als je een challenge gebruikt) alsnog mee/(na)sturen naar de gebruiker.

Ik daag je uit om met een betere methode te komen dan de hash(hash(ww+hash(username))+challenge) die daadwerkelijk de beveiliging naar een hoger plan tilt.

Voor mij belangrijk:
* minimale kosten
* geen beveiliging door source te verbergen (open source)
* beveiligen van het wachtwoord zelf heeft basisprioriteit
* authenticatie is de tweede

@ViNyL
Je hebt het over https en komt met een source pagina. Voor ik mij verdiep in die source. Mag ik er van uitgaan dat dit https gebruikt wat op standaard hosting provider draait? Ik kreeg namelijk niet de indruk dat de pagina daar over gaat.

@Cartman!
De reden dat je je database salt is dat er een injection plaats vind, toch. Natuurlijk moet je dit voorkomen maar je mag er niet vanuit gaan.

[.oisyn]

mace schreef op woensdag 18 augustus 2010 @ 16:55:
[...]

Subject Alternative Names extensie werkt anders behoorlijk goed.

Vaag dat ik daar dan weer niets over lees in Wikipedia: Server Name Indication

[ Voor 40% gewijzigd door .oisyn op 18-08-2010 16:59 ]

[Dracoo]

ajakkes schreef op woensdag 18 augustus 2010 @ 15:36:
Hij is echter wel afhankelijk van javascript. Zonder javascript valt de beveiliging tegen plaintext ww versturen en het challenge/response systeem weg. Maar dat is een gebruikerskeuze. Ik heb mijn best gedaan.

Dat hoeft natuurlijk niet: als javascript uit staat kun je php het hash-werk gewoon laten doen. Hoeft alleen maar met een vlaggetje aan te geven of het wachtwoord gehashed is ja/nee.

Oke.. je stuurt het ww in dit geval gewoon plaintext door. Het is de vraag of je dit wilt natuurlijk, maar je bent in ieder geval niet meer afhankelijk van javascript (iets wat IMHO voor geen enkele site wenselijk is).

[ajakkes]

@mace.

Ik kan me er eens in verdiepen, maar begrijp dat jij dat al gedaan hebt.

Voor zover ik weet is voor SSL
* een certificaat nodig, welke aangeschaft moet worden
* een eigen ip nodig, wat niet iedere hostingdiscounter aanbiedt
* voor ieder domein/hosting een apart certificaat nodig

Het gaat tot nu toe om basisbeveiliging
* kosten/baten vallen dus zeer snel richting geen kosten
* ik ben afhankelijk van wat de klant afneemt als hosting (kan altijd basiseisen neerleggen natuurlijk)
* als ik zelf het certificaat afneem voor al mijn klanten en dit aan verschillende domeinen koppel moet het wel werken.

edit:
@Dracoo
Yep zo werkt het op dit moment. Als javascript faalt komt het wachtwoord plain text over en werkt alles nog steeds. Er vallen wel twee beveiligingen weg. client side salt en challenge/responce. De database beveiliging werkt wel nog steeds.

[ Voor 17% gewijzigd door ajakkes op 18-08-2010 17:19 ]

[Verwijderd]

ajakkes schreef op woensdag 18 augustus 2010 @ 16:58:
@anton_89

Als de hacker toegang heeft tot de gebruikersnaam/wachtwoord hash(wachtwoord + salt) (lijkt mij?) in de database heeft hij ook toegang tot de salt in die database. (Kans is volgens mij heel klein dat het niet zo is).

Om de hacker geen toegang tot de site te geven als hij toegang heeft tot de username/wachtwoord zal je dus de salt moeten opslaan in je filesystem. Als je niet wil dat het wachtwoord op straat ligt moet je hash(wachtwoord+salt) opslaan in je database.

Ik mis even waarom je de salt zo graag uit handen van een attacker wilt houden. Je bent dan vatbaar voor een dictionary attack, maar in je protocol geef je het salt van alle gebruikers vrij. Dus het apart opslaan van het salt heeft volgensmij geen nut.

Ik daag je uit om met een betere methode te komen dan de hash(hash(ww+hash(username))+challenge) die daadwerkelijk de beveiliging naar een hoger plan tilt.

Ah, een challenge
Mijn response:

De aanpassing die .oisyn voorstelde. Dan stuurt de client twee hashes met verschillend salt terug, hash(ww+salt2), hash(hash(ww+salt1)+challenge). In de db staan dan hash(hash(ww+salt2)+salt2) en hash(ww+salt1).

Wat ik persoonlijk eleganter zou vinden is als je RSA erbij pakt. Dan kun je een heel simpel protocol aanhouden:

client -> wil inloggen -> server
server -> challenge, publickey -> client
client -> response=encrypt(publickey, challenge+ww+username) -> server
server: decrypt(privatekey, response)
en dan heeft de server de challenge+ww+username zonder dat er ooit salt of een plaintext wachtwoord over the wire is gegaan. Het wachtwoord sla je op als salted hash in de db, zoals je normaal zou doen.

Als je 'javascript rsa implementation' door google haalt krijg je resultaten genoeg. Dus dat moet niet zo'n probleem zijn lijkt mij

Voor mij belangrijk:
* minimale kosten

Mij lijkt dan een SSL certificaatje minder kost dan de tijd die jij hier nu insteekt. (Tenzij je het vaker gaat gebruiken/non-profit doet/etc, dat kan ik niet beoordelen natuurlijk)

@Cartman!
De reden dat je je database salt is dat er een injection plaats vind, toch. Natuurlijk moet je dit voorkomen maar je mag er niet vanuit gaan.

Helemaal mee eens!

[ajakkes]

Het is niet dat ik de salt uit handen van de hacker wil houden. Ik begreep alleen van jou/iemand anders dat dat handig was voor als de hacker toegang heeft tot de database en je dan voorkomt dat de hacker met alleen toegang tot de velden username/ww onder de gebruiker kan inloggen. Hij heeft immers ook de salt nodig die in het filesystem staat. Al denk ik nog steeds dat het de beveiliging heel erg verhoogd.

In mijn systeem heeft iedere gebruiker een eigen salt zodat voor iedere gebruiker een eigen rainbow table nodig is.

Ik ga morgen eens kijken naar je RSA verhaal.

[ViNyL]

Voor RSA is een mooie oplossing als je tenminste met PHP werkt, nadeel is natuurlijk wel dat je clients javascript moeten ondersteunen. Doen ze dit niet, dan valt dit deel weg en zal het alsnog plain text over de lijn gaan, mits je dat afdekt met SSL.

http://www.jcryption.org/

[Cartman!]

Ik salt m'n passwords niet specifiek voor SQL-injection maar voor het geval een ander, op welke manier dan ook, toegang krijgt tot de database. Als je dit alleen doet vanwege SQL-injectie dan weet dus blijkbaar al zeker dat je daar vatbaar voor bent. Kun je beter de tijd in dit topic besteden om SQL-injectie te voorkomen...

[joppybt]

ajakkes schreef op woensdag 18 augustus 2010 @ 17:17:
Voor zover ik weet is voor SSL
* een certificaat nodig, welke aangeschaft moet worden
* een eigen ip nodig, wat niet iedere hostingdiscounter aanbiedt
* voor ieder domein/hosting een apart certificaat nodig

Weliswaar ietwat offtopic maar: een webserver certificaat staat helemaal los van ip-adressen. Anders zou je al problemen krijgen in een load balanced omgeving waar eindgebruikers naar verschillende servers (ip-adressen) geredirect worden.
Een certificaat is alleen gekoppeld aan de domeinnaam: www.joudomein.nl bijvoorbeeld.
Zo'n certificaat heb je vanaf een paar tientjes per jaar.

[RobIII]

joppybt schreef op woensdag 18 augustus 2010 @ 22:46:
[...]

Weliswaar ietwat offtopic maar: een webserver certificaat staat helemaal los van ip-adressen

Waar ajakkes op doelt is dat een certificaat niet met virtual hosts overweg kan en je dus een dedicated IP moet hebben voor een site. Op shared hosting is dat vaak/meestal niet het geval Volgens mij is er met wat kunst-en-vliegwerk wel een mouw aan te passen maar bij mijn weten werkt dat bar slecht.

[joppybt]

Ok, zo ja. Verschillende sites met verschillende certificaten achter één IP-adres is inderdaad op zijn minst problematisch zo niet onmogelijk.

[mace]

.oisyn schreef op woensdag 18 augustus 2010 @ 16:59:
[...]


Vaag dat ik daar dan weer niets over lees in Wikipedia: Server Name Indication

Ja, ik vergiste me een beetje, het heet subjectAltName, maar dat is een klein verschil en het staat er toch duidelijk in:

Alternatively, the X.509 v3 specification introduced the so-called subjectAltName field which allows one certificate to be used for more than one domain (including wildcard domains). Therefore a single certificate can be served for all virtual domains hosted on a single server. An advantage of the subjectAltName is that, unlike SNI, it's already supported by a wide range of software.

Ik gebruik ze intern voor de servers op het werk, zodat ze op de korte hostname, FQDN en op servernaam bereikbaar zijn zonder dat de browser klaagt over ongeldige certificaten.

Werkt prima kan ik je vertellen. Je moet wel je ssl.cnf aanpassen voordat je het certificaat aanmaakt.

ajakkes schreef op woensdag 18 augustus 2010 @ 17:17:
@mace.

Ik kan me er eens in verdiepen, maar begrijp dat jij dat al gedaan hebt.

Voor zover ik weet is voor SSL
* een certificaat nodig, welke aangeschaft moet worden
* een eigen ip nodig, wat niet iedere hostingdiscounter aanbiedt
* voor ieder domein/hosting een apart certificaat nodig

Het gaat tot nu toe om basisbeveiliging
* kosten/baten vallen dus zeer snel richting geen kosten
* ik ben afhankelijk van wat de klant afneemt als hosting (kan altijd basiseisen neerleggen natuurlijk)
* als ik zelf het certificaat afneem voor al mijn klanten en dit aan verschillende domeinen koppel moet het wel werken.

Ja goed maar jij steekt nu een aantal uur in een oplossing, die manuren zijn ook niet gratis, toch?
En begrijp me niet verkeerd, maar alles wat jij in elkaar kan klussen zal nooit zo goed of veilig zijn als een goed geconfigureerde SSL verbinding.

En zoals eerder gezegd is een SSL cert op hostnaam, niet op ipadres, dus dat moet geen probleem zijn.

IMHO is SSL een veel betere optie.

[ Voor 88% gewijzigd door mace op 18-08-2010 23:52 ]

[t_captain]

Verwijderd schreef op woensdag 18 augustus 2010 @ 18:14:
[...]
Wat ik persoonlijk eleganter zou vinden is als je RSA erbij pakt. Dan kun je een heel simpel protocol aanhouden:

client -> wil inloggen -> server
server -> challenge, publickey -> client
client -> response=encrypt(publickey, challenge+ww+username) -> server
server: decrypt(privatekey, response)
en dan heeft de server de challenge+ww+username zonder dat er ooit salt of een plaintext wachtwoord over the wire is gegaan. Het wachtwoord sla je op als salted hash in de db, zoals je normaal zou doen.

Er is nog een alternatief voor RSA / public key crypto, namelijk een Massey-Omura 3 pass exchange om de session key uit te wisselen. Zie Wikipedia: Three-pass protocol.

Twee issues:
- ten eerste heb je een extra pass bij het opzetten van de verbinding.
- je bent afhankelijk van het gebuik van commutatieve berekeningen voor de ciphers, dus C1(C2(m)) == C2(C1(m)) met C1 := cipher functie 1 en C2 := cipher functie 2. Stream ciphers voldoen in het algemeen aan dit vereiste. Wel een goede stream cipher (zie e-stream project kandidaten zoals hc256) gebruiken natuurlijk en niet eentje met zwaktes zoals RC4.

Als je 'javascript rsa implementation' door google haalt krijg je resultaten genoeg. Dus dat moet niet zo'n probleem zijn lijkt mij

Bij importeren van externe code natuurlijk wel controleren dat de output gelijk is aan de output van een vertrouwde RSA implementatie, of met een test vector uit een specificatiedocument vergelijken.

Verder moet je bij RSA bedacht zijn op het feit dat er een relatie bestaat tussen de sleutel en de rekentijd. Controleer dus dat je implementaties dit informatielek dichten door de rekentijd onvoorspelbaar te maken (bv een stukje pseudo berekening toevoegen).

[ajakkes]

Wat ik nog een beetje mis bij de 3PX (3 pass exchange) en misschien ook wel bij RSA is de beveiliging als de source op straat ligt.

3PX gaat ervan uit dat de gebruiker een encrypt en decrypt key kiest om het wachtwoord te beveiligen. Voor zover ik het begrijp moet hij dat zelf doen? Of ik moet hem een aantal opties aanreiken waar hij uit kan kiezen?

Ik vraag op dit moment niet meer van de gebruiker dan een gebruikersnaam en wachtwoord en het eenmalig klikken op een knop. De drempel ligt dus erg laag.
Het wachtwoord van de gebruiker is beschermt. Hackers kunnen mijn site dus niet gebruiken om onder de naam van de gebruiker in te loggen op belangrijkere sites.
Ik kan de source van de pagina vrij delen met iedereen. Ik moet er alleen voor zorgen dat de source op de site niet aangepast wordt en de hacker geen toegang heeft tot de database. Mocht dit wel het geval zijn wis ik het wachtwoord veld, pas ik de eerste hash methode aan en laat ik iedereen opnieuw aanmelden. Waarschijnlijk door gebruik te maken van email notificatie. De gebruiker kan hetzelfde wachtwoord gebruiken (niet de veiligste keuze maar het kan)

Voordelen:
* Open source veiligheid
* Originele wachtwoord veilig
* Authenticatie klopt zolang de database verborgen is
* Minimale kosten bij hergebruik (slechts ontwikkeling, tevens leerproces)
* Minimale drempel voor de gebruiker

Nadelen:
* Een deel van de beveiliging vereist javascript
* Bij een slechte hash/salt methode hash(wachtwoord+hash(gebruikersnaam)) is een rainbow attack mogelijk per gebruiker.

Want de hash(gebruikersnaam) is, is bekend. De eerste optie is dus hash(asdf+BeKenD) waarbij asdf staat voor een van de meest gebruikte wachtwoorden en BeKenD voor de hash van de gebruikersnaam.

Om wachtwoord reset te kunnen doen zit ik te denken aan hash(ww+hash(gebruikersnaam)+public-code) waarbij de public code veranderd per site (en eventueel is opgeslagen in het filesystem, voegt denk ik weinig toe).

[t_captain]

ajakkes schreef op donderdag 19 augustus 2010 @ 10:19:
Wat ik nog een beetje mis bij de 3PX (3 pass exchange) en misschien ook wel bij RSA is de beveiliging als de source op straat ligt.

Bij RSA ligt de source al jaren op straat en banken vertrouwen er nog steeds op
Eerlijk, dit punt ontgaat me een beetje. RSA en 3PX baseren geen van beide op "security through obscurity".

3PX gaat ervan uit dat de gebruiker een encrypt en decrypt key kiest om het wachtwoord te beveiligen. Voor zover ik het begrijp moet hij dat zelf doen? Of ik moet hem een aantal opties aanreiken waar hij uit kan kiezen?

3PX dient niet om je wachtwoord over te sturen maar om een session key te synchroniseren.

SERVER: generate session key --> M
SERVER: encrypt session key --> C1(M)
SERVER: transmit encrypted session key C1(M) to client
CLIENT: encrypt session key again --> C2(C1(M))
CLIENT: transmit encrypted session key C2(C1(M)) to server
SERVER: decrypt session key --> C1^-1(C2(C1(M))) = C2(M)
SERVER: transmit encrypted session key C2(M) to client
CLIENT: decrypt session key --> C2^-1(C2(M)) = M

Nu hebben beide partijen dezelfde session key. Vervolgens gebruik je deze om de communicatie (bv username/wachtwoord) te beveiligen.

De belangrijkste zwakte zit in het feit dat het 3PX systeem vertrouwt op de client. Zou deze een zwakke cipher functie C2 gebruiken (bv NULL cipher) dan valt M te kraken uit C2(M). Daarom is het van belang dat iedere sessie een andere session key heeft. Dan heeft een aanvaller met deze aanpak alleen zijn eigen session key te pakken.

Wel opletten voor:
- manipulatie van client code die van je server wordt gedownload (bv de JavaScript code in je HTML pagina's)
- man in the middle attack (maar dat probleem heb je ook met RSA of andere public key gebaseerde systemen als je geen authenticatie van de client toepast)

Nadelen:
* Een deel van de beveiliging vereist javascript

Iedere cryptografische beveiliging heeft code aan twee kanten nodig om een communicatiekanaal te beveiligen. Dat kan SSL zijn, dan zit de client side code in je web browser. Of een protocol wat je voor je site zelf ontwikkeld in de presentatie laag, zoals jij voorstelt.
In dat geval kom je uit bij Javascript, Java applets of .NET webapplicaties met een deel van de code (runat=client). Dus een afhankelijkheid van client code zul je altijd hebben.

[ViNyL]

Wat sowieso al is aangegeven is dat je heel veel tijd stopt in het ontwikkelen en uitzoeken van dit hele proces. Ik weet niet wat het doel van de site wordt maar als dit geen ontzettend spannende dingen gaat opslaan waarom zou je dan al deze moeite nemen?

[ajakkes]

Waar ik met open source op doel is dat de code die de encryptie key maakt op straat ligt. Ik heb mij nog niet volledig in 3PX en RSA verdiept om in te kunnen schatten of dit een probleem is. Daarnaast is het zo dat ik aan de client side alleen code kan uitvoeren die ik zelf verstuur en niet alleen naar de client maar ook naar de hacker.

De encryptie key moet dus random gegenereerd worden. En de encryptie methode zelf moet dus niet een deel van de beveiliging zijn, slechts de random key. Deze moet (dacht ik) aan bepaalde voorwaarden voldoen en de voorwaarden moet ik meesturen naar de client. Mits er genoeg Random keys aan de voorwaarden voldoen is dit natuurlijk geen probleem.

Maar ik begrijp dat 3PX vooral bedoeld is als aanvulling op de huidige methode. Bijvoorbeeld voor het veilig overzenden van de challenge of het in stand houden van de beveiliging gedurende de rest van de sessie.

Je laatste punt:
Iedere beveiliging (behalve ssl (mag als standaard worden beschouwd)) is afhankelijk van toestaan uitvoeren code aan client side. Daar ben ik het mee eens, het blijft daarmee natuurlijk wel een nadeel.

Als de javascript aangepast wordt door de man in the middle heb ik inderdaad een lek. Al is het maar omdat na invoeren van wachtwoord het wachtwoord alsnog encrypted en unencrypted verzonden kan worden. En de hacker zonder dat iemand daar iets van merkt het wachtwoord zelf in handen heeft.

Ook hier helpt alleen SSL tegen.

@ViNyL.
Als er geen eenvoudige beveiligingslagen meer langs komen en er geen grove fouten worden ontdekt in de huidige methode zal ik inderdaad de huidige methode blijven toepassen. De ontwikkeling van die code heeft niet heel veel tijd gekost. Maar me wel veel geleerd.

Waar ik me nog wel echt in moet verdiepen is xhr. Niet specifiek voor deze toepassing maar zeker handig.

[ Voor 11% gewijzigd door ajakkes op 19-08-2010 11:55 . Reden: @ViNyL ]