Ja, maar om achter de functie te komen (mits goed gemaakt) dan zouden ze de code moeten hebben. En als ze die niet hebben... dan wordt het toch knap lastig lijkt me zo...
Dat klopt, maar ik ga er altijd voor de zekerheid vanuit dat als er iets mis is, er ook toegang is tot de webroot. Vaak zal dat niet voorkomen, maar ik ga er toch maar vanuit.
Het komt er ook op neer dat het een goede toevoeging is, immers stel dat ze de code hebben is de situatie weer terug naar dezelfde "we slaan een andere salt per gebruiker op in de database" situatie.
Mja, maar ik denk dat als ze toegang tot de root hebben dat het dan einde verhaal is.
Maar stel dat je de salt volgens een andere methode: verstoppen in het volle zicht. Je slaat de salt gewoon in de db op, alleen heb je er wat simpels mee gedaan. Bv je salt is abcdefg. Vervolgens doe je voor de 'versleutelde' salt een chr +2. Je krijgt dan bcdefghi. Dit lijkt een gewone salt, dus de hacker gaat hiermee aan de gang. Je brengt de hacker dan gewoon op het verkeerde pad.
Ps het was een voorbeeld, dus alles vereenvoudigd.
Of wat dacht je van een unieke id genereren en deze opslaan in de db. En dan een functie maken die je voedt met de unieke id en het e-mailadres... en daar komt dan weer je salt uit :D
Kan ook. Maar mijn bedoeling was om een salt in de db te zetten die lijkt op een echte salt. Gewoon om op het verkeerde been te zetten
Ik snap het... maar heeft de topicstarter inmiddels al antwoord op zijn vraag?
Ik zou zeggen van wel. Maar ik vraag het bij deze aan de starter: heb je je antwoord?
Mijn vraag is nu inderdaad duidelijk geworden.
Ben alleen nog wel even benieuwd wat de beste plaats is voor de statische salt. Inlcude-bestand buiten de root of in het php.ini bestand. (of ergens anders?)
Buiten de root lijkt me sowieso veiliger, maar dat geldt voor alle bestanden eigenlijk. En dan zou je het in een settings bestand kunnen zetten of in de functie zelf.
Tijden veranderen
