[php+mysql]inlognaam en wachtwoord hashen?

[Paultje3181]

Is het mogelijk om een inlognaam en het bijbehorende wachtwoord te hashen en dan op te slaan in een mysql-tabel? Ben aan het kijken om een website te maken met sterk privacy-gevoelige info waardoor ik eigenlijk niet de naam/inlognaam gekoppeld wil hebben aan deze gegevens. De tabel wordt:
inlog (hashed) | pw (hashed) | Mysql-ID | Ander uniek nummer | Privacy gevoelige info

Kan dit überhaupt? Ik ben het volgens mij nog nooit ergens tegen gekomen...

[GlowMouse]

Waarom zou het niet kunnen? Als je je dit afvraagt, vraag ik me af of je de juiste persoon bent om iets te programmeren waar sterk privacy-gevoelige info mee verwerkt wordt.

[ Voor 74% gewijzigd door GlowMouse op 29-10-2009 23:46 ]

[CodeCaster]

Als je het terug wil kunnen halen moet je het niet hashen, maar encrypten

[TeeDee]

* TeeDee vraagt zich ook af of het wel nodig is om de loginnaam te hashen.

@visvogelstar: wtf... serieus?

[ Voor 18% gewijzigd door TeeDee op 30-10-2009 00:01 ]

[Verwijderd]

Je kunt beter de gevoelige info encrypten met een lange key, je php code met ioncube encrypten en een SSL verbinding gebruiken. Misschien de inlognaam koppelen aan een telefoonnummer en een sms sturen met een uniek aangemaakte code voor het inloggen... Dan ben je wel redelijk veilig, mits je natuurlijk ook sterke FTP wachtwoorden gebruikt e.d.

edit:
@TEEDEE:
Wat bedoel je? Ik ben serieus...

[ Voor 7% gewijzigd door Verwijderd op 30-10-2009 00:02 ]

[Kettrick]

Verwijderd schreef op donderdag 29 oktober 2009 @ 23:59:
Je kunt beter de gevoelige info encrypten met een lange key, je php code met ioncube encrypten en een SSL verbinding gebruiken. Misschien de inlognaam koppelen aan een telefoonnummer en een sms sturen met een uniek aangemaakte code voor het inloggen... Dan ben je wel redelijk veilig, mits je natuurlijk ook sterke FTP wachtwoorden gebruikt e.d.

Als je dan toch al zo para bent wil je ook geen ftp doen, doe dan scp of sftp .

Krijg je overigens niet het praktische probleem dat je nooit een login kan resetten, omdat je (als ik het goed begrijp iig) de login naam van de klant niet eens kan zien ?

Ga je dan zelf een excel sheet bijhouden met id/klant combinaties ? of maakt je alsnog een klant omschrijving column ( wat het hele idee weer om zeep helpt ) ?

[Verwijderd]

RoeLz schreef op vrijdag 30 oktober 2009 @ 00:15:
[...]


Als je dan toch al zo para bent wil je ook geen ftp doen, doe dan scp of sftp .

Krijg je overigens niet het praktische probleem dat je nooit een login kan resetten, omdat je (als ik het goed begrijp iig) de login naam van de klant niet eens kan zien ?

Ga je dan zelf een excel sheet bijhouden met id/klant combinaties ? of maakt je alsnog een klant omschrijving column ( wat het hele idee weer om zeep helpt ) ?

Waarom de login gegevens verbergen. Wachtwoord hashen is genoeg lijkt me. telnummer encrypen en smsje met een unieke code moet voldoende zijn ;-)

[Kettrick]

Verwijderd schreef op vrijdag 30 oktober 2009 @ 00:19:
[...]

Waarom de login gegevens verbergen. Wachtwoord hashen is genoeg lijkt me. telnummer encrypen en smsje met een unieke code moet voldoende zijn ;-)

Ik krijg het idee dat TS niet wil dat er uberhaubt username "Toko X B.V." en "Stichting Y. Inc." in de database staat. Als je je klanten wel in wil laten loggen met tokox/l33tpass zou je een hash van deze twee kunnen gebruiken, eventueel met snufje zout.

Een vreemde oplossing, maar er zal vast een reden voor zijn denk ik ,TS ?

[RayNbow]

Op StackOverflow is een relevante discussie te vinden.

[RedHat]

Uhh..
Je hasht je password met sha1
Daarbij gebruik je een salt.

Dat is veilig genoeg atm.

[skabouter]

RoeLz schreef op vrijdag 30 oktober 2009 @ 00:15:
[...]
Krijg je overigens niet het praktische probleem dat je nooit een login kan resetten, omdat je (als ik het goed begrijp iig) de login naam van de klant niet eens kan zien ?
[...]

Waarom niet? Je kunt toch gewoon de hashwaarde van de gegeven username vergelijken met de hash uit de tabel en vervolgens een ww genereren en hash daarvan opslaan in de db?

[Paultje3181]

De bedoeling is dat een lokaal systeem binnen ehealthnet (artsen en apothekers) gekoppeld wordt met een externe website. In de Mysql-table op de website mag nooit of te nimmer staan welke persoon er achter een inlognaam zit, alleen welke medicatie. Dus vandaar... Dit gecombineerd met een los datacentre en een dubbele firewall moet voldoende zijn om de privacy van de patiënt te garanderen lijkt me...

En ik ga het zelf ook niet coden, maar was benieuwd of het uberhaupt kon voordat ik er een programmeur op zet...

[ Voor 12% gewijzigd door Paultje3181 op 30-10-2009 12:00 ]

[Verwijderd]

Huh ?

Dus usr2870 heeft medicijn dyxo-godmagwetenwat gekregen ?
Dan sla je toch gewoon de rest niet op in de tabel ?

[Paultje3181]

Inderdaad, en dat is zijn actieve medicatie en mag hij herhalen. De actieve medicatie wordt iedere nacht bijgewerkt en wordt op een bepaalde manier aangeleverd worden... En de meeste mensen zullen [e-mail] gebruiken oid. Dat is gewoon te gevoelig in vergelijking tot klasdfjslkdfhjsalkgh13217t487 heeft een amoxicilline kuur gebruikt. Vandaar dat ik het wil encrypten

[HuHu]

Waarom geef je Pietje Puk dan niet gewoon een nummer, koppel je dat nummer aan de medicatie, en sla je de naam-nummer koppeling ergens anders op?

[MuddyMagical]

Paultje3181 schreef op vrijdag 30 oktober 2009 @ 11:59:
De bedoeling is dat een lokaal systeem binnen ehealthnet (artsen en apothekers) gekoppeld wordt met een externe website. In de Mysql-table op de website mag nooit of te nimmer staan welke persoon er achter een inlognaam zit, alleen welke medicatie. Dus vandaar... Dit gecombineerd met een los datacentre en een dubbele firewall moet voldoende zijn om de privacy van de patiënt te garanderen lijkt me...

En ik ga het zelf ook niet coden, maar was benieuwd of het uberhaupt kon voordat ik er een programmeur op zet...

Je weet dat een los datacentre en 3 firewalls geen kans maken tegen een coding error?

Ik denk dat het inderdaad het makkelijkste is om de database van de website niet te voorzien van de persoonsgegevens. Alleen een identifier die je ook in de database van eHealthnet gebruikt. Je kan dan via een cronjob een selectieve export van de eHealthnet database elke nacht maken en die inlezen in de andere database.
Dan heb je een simpele en veilige oplossing omdat er simpelweg geen verbinding tussen die twee staat. Kan het dus ook niet fout gaan.

eHealth db	Web db
Koppelid	Koppelid
Echte naam	Medicatie
overige zooi

Zoals HuHu dus..

[Voutloos]

HuHu schreef op vrijdag 30 oktober 2009 @ 13:24:
Waarom geef je Pietje Puk dan niet gewoon een nummer, koppel je dat nummer aan de medicatie, en sla je de naam-nummer koppeling ergens anders op?

Check. Enkel als je op deze manier arbitraire id's uitdeelt voorkom je dat er een obvious relatie is.

[Paultje3181]

Dat gaat ook gebeuren, maar ik zit wel vast aan hoe het aangeleverd wordt... In ehealth zit een mensnummer. Dit wordt gekoppeld met de mysql unique id op de site en in ehealth. Maar de inlognaam moet helaas in de mysql van de externe site. En die zal vaak te herleiden zijn naar een patiëntnaam: vandaar het encrypten...

[Voutloos]

Als je het qua structuur niet kan fixen, kan je het niet goed fixen. Succes met je security through obscurity missie.

[marqram]

[b][message=32831066,noline]. De tabel wordt:
inlog (hashed) | pw (hashed) | Mysql-ID | Ander uniek nummer | Privacy gevoelige info

de volgorde van je velden dient in volgorde van lengte te zijn( voor optimale snelheid). Velden met variabele lengte(text, varchar) komen achteraan. Dus zijn de eerste velden ints(je id's), en eindig je met text en varchars.

[Spinal]

Heb je daar een bron voor? Heb daar namelijk nog nooit iemand over gehoord...

[DiedX]

Een andere gedachte. Als het geld mag kosten, is het een idee om de gebruiker te SMSen met een eenmalige hash?

(en niet om TS' vraag, maar dit is toch wel de reden waarom ik niet mee doe met het EPD. De koppeling, en vage koppelingen waarbij niemand meer exact weet hoe het in elkaar zit... Brrr)

[PeetR]

Mijn vraag is eigenlijk wie er dan toegang hebben tot die externe website?
Artsen en apothekers moeten toch weten voor wie medicijnen bedoelt zijn, dus voor hun moet de identiteit juist bekend zijn. Als patiënten zelf toegang hebben krijgen ze toch alleen die medicijnen te zien die ze zelf gebruiken?
Als het bedoelt is voor statistieken o.i.d. dan zijn patiëntgegevens helemaal niet van belang en worden die dus helemaal niet opgenomen.

Ik zie het probleem niet helemaal zeg maar.

[Voutloos]

marqram schreef op zondag 01 november 2009 @ 23:22:
[...]
de volgorde van je velden dient in volgorde van lengte te zijn( voor optimale snelheid).

offtopic:
Nope, onzin. Variabele lengte achteraan werkt wel onder specifieke omstandigheden, maar dat is een micro optimalisatie welke absoluut zonde van je tijd is. Het tikken van deze post kostte al meer tijd dan het ooit bespaart heeft.

[marqram]

@zanderz & @hierboven:

Ik heb hier geen bron voor kunnen vinden op internet. Deze informatie komt van mijn voormalige werkgever. Aangezien hij afgestudeerd is op database-optimalisatie en ik niet en geen bronnen kon vinden die dit tegenspreken, heb ik dit van hem voor waar aangenomen.
De redenatie achter deze werkwijze zou zijn dat bij het zoeken in een database-rij het sneller zou zijn als velden met vaste lengte vooraan staan, zodat deze velden in zijn geheel geskipt kunnen worden(lengte is immers bekend.) Bij een variabel veld zou het hele veld doorlopen moeten worden wat uiteraard meer tijd kost.
Echter snap ik dat dit slechts bij veel queries wat uit gaat maken, en dus voor TS niet heel erg van belang is. Desalniettemin een goede gewoonte om het aan te leren?
Volgens mijn werkgever had het wel degelijk effect op de tijd die zijn scripts in beslag namen.

[Woy]

marqram schreef op maandag 02 november 2009 @ 10:28:
@zanderz & @hierboven:

Ik heb hier geen bron voor kunnen vinden op internet. Deze informatie komt van mijn voormalige werkgever. Aangezien hij afgestudeerd is op database-optimalisatie en ik niet en geen bronnen kon vinden die dit tegenspreken, heb ik dit van hem voor waar aangenomen.
De redenatie achter deze werkwijze zou zijn dat bij het zoeken in een database-rij het sneller zou zijn als velden met vaste lengte vooraan staan, zodat deze velden in zijn geheel geskipt kunnen worden(lengte is immers bekend.) Bij een variabel veld zou het hele veld doorlopen moeten worden wat uiteraard meer tijd kost.
Echter snap ik dat dit slechts bij veel queries wat uit gaat maken, en dus voor TS niet heel erg van belang is. Desalniettemin een goede gewoonte om het aan te leren?
Volgens mijn werkgever had het wel degelijk effect op de tijd die zijn scripts in beslag namen.

Sowieso is het als generieke opmerking pertinent onwaar. Er is namelijk helemaal niet gedefineerd hoe een RDBMS zijn data op moet slaan, of moet query'en. Het zou dus hooguit waar kunnen zijn bij een specifiek RDBMS.

[Voutloos]

En ik ben zeker van mijn zaak, en dat van die variabele velden achteraan is idd wel te vinden in de mysql docs. Maar het blijft micro en offtopic.

[ Voor 4% gewijzigd door Voutloos op 02-11-2009 11:09 ]

[Woy]

Voutloos schreef op maandag 02 november 2009 @ 11:09:
En ik ben zeker van mijn zaak, en dat van die variabele velden achteraan is idd wel te vinden in de mysql docs. Maar het blijft micro en offtopic.

offtopic:
Idd erg offtopic, maar dat is exact wat ik zeg. Het is afhankelijk van het RDBMS. Dus het kan best zo zijn dat het in MySql een (marginale) performance winst geeft. Echter is dat niet iets wat je generiek over alle RDBMS'en kunt zeggen