Nødvendig med kryptering ved web innlogging?

[Giddion]

Beklager hvis det ikke hører hjemme her, men jeg lurer på hvor nødvendig/kritisk det er med kryptering når man sender innloggings info (passord og brukernavn) over internett.

 

Jeg kjenner noen som har kjøpt en CMS løsning, men når jeg logger inn og bruker wireshark så ser jeg innloggings infoen klart og tydelig. Så det jeg egentlig lurer på er om dette en grunn til kritikk eller ikke.

 

Det er vel egentlig ikke noe problem så lenge man stoler på sin isp og ikke bruker trådløst, men jeg er ikke inne i bransjen så jeg er usikker på hvor nødvendig bransjen ser på dette.

 

Takker for alle svar.

Endret 4. mars 2010 av Giddion

[duckers]

Dette er et typisk eksempel på dårlig praksis ja.

 

Det er ikke nødvendig med kryptering av passordet (type TLS), men det burde hases med gode og varierende salter slik at dette ikke kan snappes opp over nettverket.

 

Dog, dersom dette er en CMS der det går data av sensitiv karakter ville jeg benyttet TLS uansett.

[Giddion]

Den er god, takker for god input.

[nomore]

Dette er nok ikke sikkert CMS-løsningen sin feil. Hadde CMS-løsningen vært installert på et webhotell/webserver med HTTPS og sertifikat, så hadde hele problemstillingen vært ikke-eksisterende. Og dette står kanskje i installasjonsmanualen?

[MailMan13]

Det er ikke wireshark som ser "gjennom" evt. SSL/https da?

 

Fiddler kan vel det. Den setter seg opp som proxy og dekrypterer/krypterer on-the-fly (man-in-the-middle).

 

Uansett, løsningen er et sertifikat + https på serveren, om ikke bombesikkert så går det ihvertfall ikke i klartekst. Har ærlig talt aldri sett noen som hasher passordet på klienten (javascript?) før det sendes inn heller.

[duckers]

Wireshark kan ikke se innholdet i krypterte pakker, og med mindre andre programmer fanger opp pakkene før de blir kryptert inne i programmet som kjører (lese minnet?), så kan ikke de heller lese innholdet. Man in the middle må opprettes i det den sikre forbindelsen mellom klient og tjener opprettes.

 

Mulig det ikke er så vanlig med hashing på klienten før passordet sendes, men det er vel den eneste "fattigmans" løsningen for å forhindre at passordet sendes ukryptert over nettverket. Dette må implementeres i javascript, flash, java etc.. Slike løsninger vil uansett være sårbare under opprettelsen av passordet, så SHTTP er nok å foretrekke.

[Terrasque]

Wireshark kan ikke se innholdet i krypterte pakker, og med mindre andre programmer fanger opp pakkene før de blir kryptert inne i programmet som kjører (lese minnet?), så kan ikke de heller lese innholdet. Man in the middle må opprettes i det den sikre forbindelsen mellom klient og tjener opprettes.

 

Mulig det ikke er så vanlig med hashing på klienten før passordet sendes, men det er vel den eneste "fattigmans" løsningen for å forhindre at passordet sendes ukryptert over nettverket. Dette må implementeres i javascript, flash, java etc.. Slike løsninger vil uansett være sårbare under opprettelsen av passordet, så SHTTP er nok å foretrekke.

 

Hah, hashing på klienten er i utgangspunktet ganske ubrukelig. Tenk deg, hva er det du sender over linjen da? Det samme, faktisk. Istedet for passordet direkte, så er det hashen av passordet som bruker for autentisering. En angriper trenger da ikke vite passordet, han kan bare bruke hash'en direkte.

 

Hvis vi snakker om challenge/response derimot.. Men det krever at passordet kan lagres i klartekst på server. Man kan ta en dobbel-hashing - hash(challenge+(hash(passord))) - men da trenger man bare hash'en for å logge inn, så passordet lagres i "klartekst".. igjen..

 

Hhvis det skal krypteres, så bruk https.

[siDDis]

Det som kan gjeres er å lage ein Java applet som kommuniserer kryptert. Også bruke Javascipt til å oppdatere nettlesaren.

[duckers]

Hvis vi snakker om challenge/response derimot.. Men det krever at passordet kan lagres i klartekst på server. Man kan ta en dobbel-hashing - hash(challenge+(hash(passord))) - men da trenger man bare hash'en for å logge inn, så passordet lagres i "klartekst".. igjen..

 

Må si meg enig med deg.

 

Det jeg tenkte på var hash(variabel-salt+hash(salt+passord)). På denne måten må de få tak i hash(salt+passord). Dette er i prinsippet ikke er noe verre enn å få tak i det reine passordet, men du slipper en av de andre fellene, nemlig lagring av passord i klartekst, passordet kan heller ikke snappes opp i en pakke, siden den hashen som sendes over nettverket er forskjellige hver gang.

 

Men ja.. TLS eller OpenID er nok veien å gå..

[Giddion]

Dette er nok ikke sikkert CMS-løsningen sin feil. Hadde CMS-løsningen vært installert på et webhotell/webserver med HTTPS og sertifikat, så hadde hele problemstillingen vært ikke-eksisterende. Og dette står kanskje i installasjonsmanualen?

 

Jeg var uklar der, tjenesten som kjøpes innholder både drift, installasjon og selve softwaren.

[nomore]

Men har dere fått tilbud om å kjøre på HTTPS? Et sertifikat koster penger og da blir driften/tjenesten dyrere. Om det da er valgt det billigste alternativet så kan kan ha valgt bort dette.

[quantum]

Du har jo fått mange gode svar her allerede, men spørsmålet er det vel egentlig bare den som vet hvilken informasjon krypteringen eventuelt skulle beskyttet som kan besvare. Det er jo en drøss andre protokoller som også sender passord ukryptert, ftp, smtp etc. Ikke særlig bra, men ...

 

Siden det er et cms ... anta at noen tullefanter klarer å hacke seg inn og 1. stjele alt, og 2. legge inn uriktig informasjon. Hva er sannsynligheten for at det skjer og hva er konsekvensen? Er du f.eks. i mål ved å legge tilbake gårsdagens backup? Er siten så spennende at dette vil skje igjen og igjen, eller kun en gang pr. jubelår?

 

Sertifikater for https kan man lage seg selv kostnadsfritt. Disse gir da ikke brukerne noen sikkerhet mht. sitens autentisitet, men krypteringen fungerer like fullt. Brukerne må også da få forklart at det ikke er farlig å bruke løsningen selv om de får en trillion advarsler fra browseren sin. Hvis hensikten f.eks. er kryptering for administratorer/moderatorer på løsningen vil dette kunne funke, men det vil se altfor uprofft ut dersom det skulle tas i bruk av f.eks. alle brukerne av en kommersiell løsning.

[nomore]

Ulempen med å bruke selvsignerte sertifikater er dersom man har besøkende som sitter på sterkt regulerte maskiner(offentlige, internt i bedrifter osv). Her kan det da være lagt inn sperre på å tillate sertifikater som ikke er signert av en godkjent sertifikat leverandør. Som du er inne på så kommer jo dette også ann på hvilken brukermasse man har, men det kan også være greit å ha i bakhodet.

[Giddion]

Joda jeg har fått nok svar jeg .. svaret er jo NEI..... men det kan vært kjekt og man må ta en vurdering på om det er nødvendig...... som man forsåvidt må gjøre med det meste.

 

Takker for all svar, men dere må bare fortsette å diskutere.