[iostream]

Nyligen skapade jag ett konto hos Epay, och var tvungen att byta från temp-lösenordet när jag loggade in (bra!). Katten assisterade mig som vanligt genom att trampa runt lite på tangentbordet för att skapa ett säkert lösenord.

Your password must be max. be 20 characters long!

Eh, det är riktigt dåligt, men okej, I'll go with it -- kissen, kom tillbaka en stund.

Character "}" is not allowed in the password!
Character "{" is not allowed in the password!
Character "[" is not allowed in the password!
Character "]" is not allowed in the password!
Character "<" is not allowed in the password!
Character ">" is not allowed in the password!
Character "%" is not allowed in the password!
Character " " is not allowed in the password!
Character """ is not allowed in the password!
Character "\" is not allowed in the password!
Character "#" is not allowed in the password!

Va, vad är det för artificiell begränsning? Försöker de undvika SQL-injektioner eller något liknande som de har hört sagor om att man måste skydda sig mot, men inte fått undervisningen om hur man faktiskt gör?

Ja ja, låt oss hålla oss till endast alfanumeriskt då.

Your password does not contain any special characters! Enter one or more special characters ";,:.-_*!@$¤()=?+/" in your password.

Vad i helvete, man måste ange ett specialtecken, men det går bara med *vissa* tecken‽

Slutligen lyckades jag mata in ett lösenord som accepterades. Med alla dessa onödiga begränsningar undrar man naturligtvis hur lösenordet behandlas i systemet -- varför kan man endast ha en viss längd och vissa tecken när det ändå ska gå igenom en bunt kryptografiskt säkra algoritmer?

Vad är ett bättre sätt att testa säkerheten än att skicka en lösenordsåterställnigsförfrågan? Ett långt och knepigt ord, men inte i närheten av hur knepigt det är med grundläggande datorsäkerhet, tydligen.

Hi

You requested your login to the payment system. You can login with the following information:

Username: <username>
Password: <my previous password>

Link: https://ssl.ditonlinebetalingssystem.dk/admin/

Kind regards
ePay

Som jag misstänkte, lösenordet jag tidigare matade in kommer tillbaka i klartext i mailet...

Inte nog med det, det finns en URL man kan GET-anropa för att automagiskt och direkt bli inloggad i administrationspanelen med full åtkomst, med formatet:

https://ssl.ditonlinebetalingssystem.dk/admin/checklogin.asp?all=1&lid=<user ID>&seckey=<secret MD5 key>

Detta är alltså en betaltjänstleverantör som inte kan grundläggande datorsäkerhet (eller hur man tillhandahåller en webbsida; många länkar är brutna och annat halvt trasigt).

Jag är inte expert på området, men bör inte kompetens krävas av PCI-certifieringen?

TL;DR: Epay.se har ingen aning vad de sysslar med och lagrar lösenord i klartext och har magiska URLer för direkt inloggning.

[Reconsider]

Grymt pinsam läsning. Bra!

[jayzee]

En tumregel är att så fort du ser att de har begränsning på lösenordets maxlängd kan du räkna med att den lagras i klartext.

[Westman]

Det kan vara begränsningar i tredjepartsprogramvara som gör att vissa specialtecken inte fungerar. Jag har stött på flera såna system genom åren och vi har ett antal såna i drift fortfarande - tyvärr.

Som kuriosa kan nämnas att det oftast är ekonomisystem eller personalsystem som är sämst.

[Clarence]

Jag skummade igenom PCI DSS (Payment Application Data Security Standard) och det verkar som om det de senaste 3 åren (med PCI DSS 2.0) inte varit krav på envägskryptering av lösenord men att det kom först i November (med PCI DSS 3.0).

Så det kan tyvärr vara så att de följer (den gamla) standarden för branchen för lagringen då det är tillåtet att lagra lösenordet med tvåvägs-kryptering. Däremot så säger den också att lösenorden måste skyddas av "strong cryptography during transmission" och det kan väl ändå inte gå ihop med att skicka lösenordet i mail??

Sen förklarar dettta förvisso inte de väldigt konstiga begränsningarna de har för lösenordet. Det tyder ju på att det helt emot standarden faktiskt lagras i klartext ändå.

Men i PCI-DSS 3.0 har de äntligen bytt ut "strong cryptography during transmission and storage" till "strong cryptograhy during transmission" och "strong, one-way cryptographic
algorithm" för storage.

[tartareandesire]

Varför inte kontakta Epay först och hör vad de har att säga? Kanske planerar de redan att byta ut sitt system? Nu hänger du inte bara ut företaget utan du utsätter dessutom alla deras kunder för onödiga risker.

[ePay-SE]

Hej iostream

Tack för din feedback - det är oerhört viktigt för oss!

Först och främst kan jag meddela att vi håller på att programmera en ny version av betalningssystemet/admin gränssnittet, så du inte behöver fråga katten varje gång du ska logga in eller skapa ett nytt lösenord.
- Förmedlingen av lösenordet kommer även att ske på annan vis.

Till info så utgör detta inte en säkerhetsrisk angående kortuppgifter, eftersom man under inga omständigheter kan se dem i admin gränssnittet. Det är alltså inte möjligt att extrahera kortnummer och andra känsliga uppgifter omkring kosumenten via företagets admin gränssnitt.

Detta omfattas ej av PCI-reglerna eftersom det inte har något med kortuppgifter att göra.

Därför är det bäst för alla parter att det ska vara så lätt som möjligt för företag att logga in/få sina uppgifter till ePay administrationen. Så vi har tills vidare valt att skicka detta oskyldiga lösenord i ett e-postmeddelande (dock enbart till den adressen/adresser som är registrerade).

Du skriver även lite om dead links på vår hemsida och jag vill gärna skriva en liten kommentar till detta också. Den primära orsaken till det är den nyliga uppdatering av själva betalfönstret och vissa lösningar/guides som ej längre är tillgängliga.
- Det är självklart något vi jobbar på att eliminera, men just nu är det nedprioriterat eftersom håller på att designa och programmera en helt ny hemsida, som vi räknar med att lancera i 2014 (exakt tidpunkt kan ännu inte avslöjas).

Ursprungligen postat av Clarence

Jag skummade igenom PCI DSS (Payment Application Data Security Standard) och det verkar som om det de senaste 3 åren (med PCI DSS 2.0) inte varit krav på envägskryptering av lösenord men att det kom först i November (med PCI DSS 3.0).

Så det kan tyvärr vara så att de följer (den gamla) standarden för branchen för lagringen då det är tillåtet att lagra lösenordet med tvåvägs-kryptering. Däremot så säger den också att lösenorden måste skyddas av "strong cryptography during transmission" och det kan väl ändå inte gå ihop med att skicka lösenordet i mail??

Sen förklarar dettta förvisso inte de väldigt konstiga begränsningarna de har för lösenordet. Det tyder ju på att det helt emot standarden faktiskt lagras i klartext ändå.

Men i PCI-DSS 3.0 har de äntligen bytt ut "strong cryptography during transmission and storage" till "strong cryptograhy during transmission" och "strong, one-way cryptographic
algorithm" för storage.

Hej Clarence

Stämmer det att du refererar till punkt 8.2.1 i PCI DSS 3.0?

I så fall, så har detta som tur är inget med lösenordet till företagets admin gränssnitt eller förmedlingen av detta att göra. Det handlar däremot om kryptering av interna uppgifter, koder och liknande hos PSP'n som har med tillgång till kortdata mm. att göra.

Vi är PCI certificerade hos både Mastercard och VISA, vilket innebär att vi uppfyller alla krav enligt PCI DSS. Certifikatet måste förnyas årligen och detta sköts alltid av en QSA (Qualified Security Assessor), för att säkra att alla nya/nödvändiga tilltag i PCI standarden tillhandahålls av PSP'n.

-------------------------------------------------------------------------

Om jag har missat något får ni gärna säga till!

Feedback välkomnas alltid på [email protected] i fall man har förslag till förbättringar av hemsida, admin gränssnitt eller själva betalfönstret.

[ePay-SE]

Ursprungligen postat av tartareandesire

Varför inte kontakta Epay först och hör vad de har att säga? Kanske planerar de redan att byta ut sitt system? Nu hänger du inte bara ut företaget utan du utsätter dessutom alla deras kunder för onödiga risker.

That's the spirit !

Ursäktar om min svenska är lite dålig (har inte bott i Sverige sen jag var 12). Så i fall något av det jag har skrivit låter helt fel, försöker jag gärna omformulera det.

[j0han]

Ursprungligen postat av ePay-SE

Så vi har tills vidare valt att skicka detta oskyldiga lösenord i ett e-postmeddelande (dock enbart till den adressen/adresser som är registrerade).

Ni måste skoja?

Ni kan ju inte se era kunders lösenord som oskyldiga och obetydliga? Lösenorden kan ju vara samma lösenord som till mail, som i sin tur leder till annat.

Ni kommer aldrig någonsin få mig som kund åtminstone.

[ePay-SE]

Ursprungligen postat av j0han

Ni måste skoja?

Ni kan ju inte se era kunders lösenord som oskyldiga och obetydliga? Lösenorden kan ju vara samma lösenord som till mail, som i sin tur leder till annat.

Ni kommer aldrig någonsin få mig som kund åtminstone.

Hej j0han

Du kanske missade något av det jag skrev i mitt första inlägg. Förmedlingen av lösenordet till admin gränssnittet håller på att bli ändrat i samband med uppdateringen av detta.

Det kommer bli lite mer klurigt att få tag på sitt lösenord, men säkerheten bör och ska vara i topp oavsett vad man får tillgång till och vad man inte får tillgång till - jag håller med dig 100%.

Kanske formulerade mig dåligt när jag sa "oskyldigt", vilket jag enbart menade i den specifika kontext, som själva ämnet handlar om, alltså kortuppgifter.