Om het gebruiksgemak te vergroten, de website te kunnen analyseren en om advertenties te kunnen beheren maakt Security.NL gebruik van cookies. Door gebruik te blijven maken van deze website, of door op de akkoord button te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer weten over cookies? Bekijk dan ons cookieoverzicht.
Nieuws Achtergrond Community
Inloggen | Registreren
Nieuws
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.

Apple verhelpt kritieke lekken in MacOS, iOS, iTunes en Safari
Microsoft: Windows 7-systemen doelwit van zeroday-aanval
Reacties (6)
Reageer met quote
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.
Reageer met quote
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.
Reageer met quote
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.
Reageer met quote
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.
Reageer met quote
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!!!
Reageer met quote
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
Ondersteunde bbcodes
Bold: [b]bold text[/b]
Italic: [i]italic text[/i]
Underline: [u]underlined text[/u]
Quote: [quote]quoted text[/quote]
URL: [url]https://www.security.nl[/url]
Config: [config]config text[/config]
Code: [code]code text[/code]

Je bent niet ingelogd en reageert "Anoniem". Dit betekent dat Security.NL geen accountgegevens (e-mailadres en alias) opslaat voor deze reactie. Je reactie wordt niet direct geplaatst maar eerst gemodereerd. Als je nog geen account hebt kun je hier direct een account aanmaken. Wanneer je Anoniem reageert moet je altijd een captchacode opgeven.

Je reactie is verstuurd en wordt zo spoedig mogelijk gemodereerd.

Verder
captcha
Nieuwe code
Preview Reageren
Zoeken
search

Social media in de toekomst:

12 reacties
Aantal stemmen: 359
Vacature
Vacature

Technisch Security Specialist

De IT in de zorg professionaliseert. De beweging naar de Cloud brengt nieuwe mogelijkheden met zich mee maar ook de noodzaak om op security gebied stappen te zetten. Wil je die stap met ons zetten en werken in een dynamische, moderne IT omgeving? Solliciteer dan op deze veelzijdige functie!

Lees meer

Welke messaging-app gebruik jij?

37 reacties
Aantal stemmen: 1297
Vacature
Vacature

Engineer IT-operations

Nationaal Cyber Security Centrum

Als engineer IT-operations werk je in DevOps-verband samen met de solution-engineers van het NCSC. Die zijn verantwoordelijk voor de implementatie, doorontwikkeling en het applicatief beheer van onze businessapplicaties. Jij vult de Ops-taken in. Jouw grootste uitdaging? Bestaande regels vertalen naar technische oplossingen.

Lees meer
Vacature
Vacature

(Senior) Solutions-engineer

Nationaal Cyber Security Centrum

Als (senior) technisch applicatie beheerder/developer ben je verantwoordelijk voor de implementatie, doorontwikkeling en het beheer van een aantal business applicaties en technische voorzieningen van het NCSC. Het gaat hierbij om applicaties en voorzieningen op het gebied van incident- en vulnerability management en malware analyse.

Lees meer
Nieuwe Huisregels en Privacy Policy

Op 5 december 2017 hebben we een nieuwe versie van onze huisregels en privacy policy ingevoerd. Om verder te kunnen gaan dien je eenmalig akkoord te gaan met de nieuwe huisregels van Security.NL.

Op 24 mei 2018 hebben we, in het kader van de AVG, onze privacy policy bijgewerkt. Om verder te kunnen gaan dien je eenmalig akkoord te gaan met de bijgewerkte privacy policy. Heb je vragen neem dan contact op met info@security.nl.

Verzenden
Privacy Policy

Op 24 mei 2018 hebben we, in het kader van de AVG, onze privacy policy bijgewerkt. Om verder te kunnen gaan dien je eenmalig akkoord te gaan met de bijgewerkte privacy policy. Heb je vragen neem dan contact op met info@security.nl.

Verzenden
Inloggen

Bedankt! Je kunt nu inloggen op je account.

Wachtwoord vergeten?
Nieuwe code captcha
Inloggen

Wachtwoord Vergeten

Wanneer je hieronder het e-mailadres van je account opgeeft wordt er een nieuwe activatielink naar je gestuurd. Deze link kun je gebruiken om een nieuw wachtwoord in te stellen.

Nieuwe code captcha
Stuur link

Password Reset

Wanneer je het juiste e-mailadres hebt opgegeven ontvang je automatisch een nieuwe activatielink. Deze link kan je gebruiken om een nieuw wachtwoord in te stellen.

Sluiten
Registreren bij Security.NL

Geef je e-mailadres op en kies een alias van maximaal 30 karakters.

Nieuwe code captcha
Verzenden

Registreren

Je hebt je succesvol aangemeld. Voordat je je account kunt gebruiken moet deze eerst geactiveerd worden. Dit kan je zelf doen middels de activatielink die naar het opgegeven e-mailadres is verstuurd.

Sluiten
Over Security.NL
Huisregels
Privacy Policy
Adverteren
© 2001-2021 Security.nl - The Security Council
RSS Twitter