Ja maar als die database goed is beveiligd of niet aan 't net hangt word het wel een stukje moeilijker niet dan.dejef

databank hoeft ook niet aan het internet te hangen, ook al hangt die alleen aan een DMZ en de webserver is publiekelijk toegankelijk en SQL injectie is mogelijk dan kan je als nog heel de databank leeg trekken.

Als wachtwoorden als platte tekst uit een database te lezen zijn, op wat voor manier dan ook, dan zijn die wachtwoorden per definitie ONVEILIG opgeslagen.

Tsja dit is wel een heel domme opmerking van Tesco.
Het verraad totale onwetendheid mbt wachtwoord encryptie.
Een goed geencrypt wachtwoord met salt vereist zoveel rekenkracht om te ontcijferen
dat het onpraktisch is om gebruikers die hun wachtwoord vergeten zijn weer van hun
opgeslagen plain tekst wachtwoord te voorzien.

In een omgeving met veilig opgeslagen (encrypted) wachtwoorden laat je gebruikers die
hun wachtwoord vergeten zijn een nieuw wachtwoord opgeven.

Ja en? Encryptie is naast hashing ook een goede manier van beveiliging!
Wat denk je wat langer duurt om te kraken md5($wachtwoord) of pgp_2048_private_key($wachtwoord)

Tsja, als ze maar niet om medelijden gaan bedelen als ze gehacked worden....

SQL injectie werkt alleen tamelijk beroerd bij een LDAP directory.

Ik snap niet zo goed hoe mensen er altijd maar vanuit gaan dat wachtwoorden in een database zitten en dat als ze een wachtwoord toegemaild krijgen, dat de wachtwoorden dan dus ook plaintext in die database staan opgeslagen en daar met een simpele SQL injectie uit te plukken zijn.

Ik weet van in elk geval één grote commerciële identity management oplossing dat die een mogelijkheid biedt om wachtwoorden met een vorm van 3DES encryptie op te slaan, waarbij de benodigde sleutels voor decryptie afgeschermd op het filesystem van de server staan. Voor een webapplicatie is dan alleen een LDAP of andere standaard interface beschikbaar waar authenticatie checks kunnen worden uitgevoerd, zonder dat het wachtwoord in kwestie ooit de directory server verlaat.

Tamelijk treurig dat so claimed beveiligingsexperts op dit vlak keer op keer naar conclusies springen zonder verder te kijken dan hun neus lang is.

(Uiteraard is het net zo treurig dat ze heel vaak wel gewoon gelijk hebben en de oplossing inderdaad verre van veilig is, maar het ontvangen van je wachtwoord via e-mail is daar geen sluitend bewijs voor)

Wanneer er 'een weg terug' bestaat, zijn er mensen die de wachtwoorden kunnen lezen. Wat dacht je van een ontevreden beheerder?
En weet je nog van LinkedIn? Toen bleken er toch wel veel mensen te zijn die dat wachtwoord ook op andere plaatsen gebruiken.

De vraag is: Is het nodig om het wachtwoord leesbaar te kunnen maken? Alleen wanneer het antwoord 'ja' is en er is geen andere manier om hetzelfde doel te bereiken, zou ik gecrypte wachtwoorden overwegen. En in de praktijk heeft zich dat nog niet voorgedaan.

Die ontevreden beheerder kan ook wachtwoorden onderscheppen die in de webapplicatie aankomen, voordat ze gehasht en wel in de database verdwijnen. Met de juiste permissies heb je in een identity management oplossing met omkeerbare crypto op de wachtwoorden ook als beheerder geen toegang tot de versleutelde wachtwoorden.
Dat soort scenario's is niet te beveiligen in de applicatie, of de database, dan heb je het over gedegen change management procedures, toegang tot privileged accounts, logging en monitoring etc.
Natuurlijk is er praktisch altijd een andere manier om het doel te bereiken. Maar bedrijven maken nu eenmaal een afweging tussen de dienstverlening die ze willen bieden en de risico's die daarbij horen. Als je voor elke afweging de meest veilige zou kiezen, dan zou geen bedrijf meer aan zaken doen toekomen. Een klant zijn 'eigen' wachtwoord teruggeven is gewoon klantvriendelijker dan hem opzadelen met een random wachtwoord wat weer moet worden aangepast. Het kan prima zijn dat Tesco hiervoor gekozen heeft, omdat ze het risico dat op deze manier wachtwoorden in verkeerde handen vallen en misbruikt worden niet op vinden wegen tegen het risico om klanten te verliezen of tegen de extra kosten voor nieuwe accounts / helpdesk calls.

Bovendien kan die keuze ook voor andere zaken zinvol zijn, zoals migraties naar een andere directory server zonder dat iedereen een nieuw wachtwoord moet kiezen, of synchronisatie van wachtwoorden tussen verschillende systemen en dergelijke.

Nogmaals: het bewijs andersom, dat ze het wel aardig op orde hebben met een dergelijke oplossing is er ook (nog) niet en er kleven inderdaad nadelen aan het gebruik van omkeerbare crypto voor dit soort toepassingen. Maar ik denk dat het goed is om de nuance te leggen dat er niet al te snel allerlei conclusies getrokken moeten worden, puur omdat je je oude wachtwoord toegestuurd krijgt.

Er wordt te makkelijk een bedrijf compleet afgefakkeld zonder te weten hoe het daadwerkelijk in elkaar steekt en dat vind ik niet zo fraai. Aandacht vragen voor security is helaas nog altijd heel hard nodig, maar er zijn grenzen.

goeiemorgen, encryptie voor wachtwoorden jongens??? alleen hashing is toegestaan voor passwoorden zodat het wachtwoord niet terug in plain text kan komen zonder het te craken.
encryptie heb je gewoon de sleutel nodig en is een groto nono.

je moet mij niet geloven, maar ik doe dit wel als mijn dagelijkse job

google.com - good password policies
encoding - no!
encryption - no!
hashing - yes

Daarom heb ik nou zo'n hekel aan het woord "industriestandaard". Een "industriestandaard" is geen standaard, het is uit gebrek aan visie en inzicht doen wat iedereen in je branche doet, zodat je als het fout gaat gewichtig kan zeggen dat je je aan die "industriestandaard" hebt gehouden. Dit zit in de hoek van: niemand is ooit ontslagen door voor X te kiezen.

Dat je hele branche om een onverantwoorde manier met wachtwoorden omgaat (want dat beweert Tesco hier) is geen excuus om het zelf ook te doen.