image

Magento-webshops bewaarden mislukte inlogpogingen klanten in plaintext

woensdag 25 maart 2020, 09:35 door Redactie, 6 reacties

Een beveiligingslek in de zeer populaire webwinkelsoftware Magento zorgde ervoor dat mislukte inlogpogingen van klanten in plaintext in de database werden opgeslagen. Hoewel het probleem inmiddels is verholpen zijn de opgeslagen gebruikersnamen en verkeerde wachtwoorden nooit verwijderd.

Daarvoor heeft Adobe, dat de Magento-webwinkelsoftware onderhoudt, een hotfix uitgebracht. Vorig jaar oktober kwam Magento met een beveiligingsupdate voor een kwetsbaarheid waardoor mislukte inlogpogingen van klanten zoals gezegd in plaintext werden opgeslagen. Een aanvaller met toegang tot de database zou op deze manier het juiste wachtwoord van gebruikers kunnen afleiden.

De beveiligingsupdate zorgde ervoor dat Magento mislukte inlogpogingen niet meer in plaintext bewaarde. Al opgeslagen inlogpogingen bleven echter gewoon in de database achter. Daarvoor is nu een hotfix verschenen, die al deze inlogpogingen verwijdert. "De informatie zou alleen toegankelijk zijn wanneer de webwinkel op een andere manier was gecompromitteerd. Desondanks raden we aan om de update zo snel als mogelijk te installeren", aldus het Magento Security Team.

Reacties (6)
25-03-2020, 10:04 door Anoniem
Zou het niet mooi zijn als we gebruik maken van een inlogmethode waarbij de server niet meer dit soort gevoelige gegevens hoeft te bewaren? Een beetje zoals SSH waarbij je met public-key authenticatie geen geheim meer op hoeft te slaan aan de server kant. Als je dat toch een keer een datalek hebt kunnen er ieder geval geen gevoelige gegevens meer gelekt worden.

#WebAuthn

Om ook iets inhoudelijker te reageren ben ik dit ook nog wel eens tegen gekomen. Het loggen hoeft zeker niet bewust te gebeuren. Wanneer je bijvoorbeeld naam en wachtwoord naar een API stuurt en hierbij niet opmerkt dat deze in de URL staan. In tegenstelling tot een POST body, zijn ze dan terug te vinden in standaard webserver logs. Daar zit dan geen kwade intentie achter, maar het is wel slordig en zorgt er voor dat wachtwoorden minder goed beschermd zijn dan wanneer deze gehashed worden.
25-03-2020, 11:24 door Briolet
Door Anoniem: Zou het niet mooi zijn als we gebruik maken van een inlogmethode waarbij de server niet meer dit soort gevoelige gegevens hoeft te bewaren? …

Die zijn er al lang. zie b.v. https://en.wikipedia.org/wiki/Digest_access_authentication

Mijn IP cameras gebruiken deze inlogmethode en ook mijn Synology nas. Het wachtwoord word lokaal gehashed via een JS en de server ontvangt alleen de hash en ziet het wachtwoord nooit. Het geheel wordt zelfs nog een keer gehashed met de session cookie.

Dus uiteindelijk dubbel gehashed zodat je er niets aan hebt als dit door een fout in het log zou komen.
25-03-2020, 15:32 door Anoniem
Door Briolet:
Die zijn er al lang. zie b.v. https://en.wikipedia.org/wiki/Digest_access_authentication

Mijn IP cameras gebruiken deze inlogmethode en ook mijn Synology nas. Het wachtwoord word lokaal gehashed via een JS en de server ontvangt alleen de hash en ziet het wachtwoord nooit. Het geheel wordt zelfs nog een keer gehashed met de session cookie.

Dus uiteindelijk dubbel gehashed zodat je er niets aan hebt als dit door een fout in het log zou komen.

Mijn punt ten aanzien van een secret-key gebaseerde authenticatie methode dat geldt ook voor digest access authentication. Of het wachtwoord nu 1 of 2 keer gehashed wordt, wanneer er een hash is valt deze te kraken middels brute force aanvallen. Sinds jaar en dag is bekend dat veel wachtwoorden niet sterk (lang en willekeurig) genoeg zijn en hergebruikt worden op meerdere sites. Dat is fundamenteel het probleem en wordt bij het gebruik an digest authenticatie niet opgelost. Met digest authenticatie voorkom je wel dat een wachtwoord per ongelukt in plaintext opgeslagen kan worden ergens aan de server kant.

De echte oplossing is dus om gebruik te maken van digitale handtekeningen (SSH authenticatie, TLS client certificates, WebAuthn) omdat een server dan alleen publieke informatie hoeft te bewaren.
25-03-2020, 15:47 door Anoniem
O dit komt vaak zat voor hoor...
Er zijn genoeg systemen waar je in de log dit soort dingen kunt vinden:
Failed password for root from .....
Dat is ook slecht want als je per ongeluk het password tikt ergens waar de user gevraagd wordt dan wordt
dit ook gelogd. Dus als er ineens iets staat van:
Failed password for idYdYtaEs3uC from ...
dan kun je er donder op zeggen dat dit het password van een van de gebruikers is.
Waarschijnlijk de gebruiker die direct daarna wel succesvol inlogt.
25-03-2020, 17:23 door Anoniem
Daarvoor was ik altijd al bang voor, dat als ik verkeerd wachtwoord intyp en het daarna op de server in plain text wordt opgeslagen als een soort van security controle tegen hackers etc. Mijn nachtmerrie is nu werkelijkheid geworden. Écht altijd oppassen op internet, want wie weet komt jouw nachtmerrie ook wel eens uit!!!
26-03-2020, 08:56 door Anoniem
Door Anoniem: Zou het niet mooi zijn als we gebruik maken van een inlogmethode waarbij de server niet meer dit soort gevoelige gegevens hoeft te bewaren? Een beetje zoals SSH waarbij je met public-key authenticatie geen geheim meer op hoeft te slaan aan de server kant. Als je dat toch een keer een datalek hebt kunnen er ieder geval geen gevoelige gegevens meer gelekt worden.

#WebAuthn
Is dit het zelfde als SAML? Ik kan er namelijk weinig over vinden wat de verschillen echt zijn.
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.