[eg0master]

Originally posted by iXam@Aug 21 2007, 14:42
Man behöver ju inte köra mer än inloggningen via SSL. Då blir ju den extra belastningen på servern minimal.

Etferosm det bara är initieringen av SSL/TLS osm är kostsam finns det egentligen ingen anledning att byta till "icke SSL" efter inloggningen när man väl satt upp en krypterad förbindelse. Nya sessionsnycklar förhandlas normalt sett inte fram förrän efter väldigt mycket trafik varför det är en onödig optimering att köra icke-SSL efter inloggningen (med de potentiella säkerhetsbristerna) jämfört med kostnaden för kryptering i en redan etablerad kanal/session.

[Anders Larsson]

83 kr i månaden för att få besökarnas förtroende är väl inte så dyrt?

[SimonP]

Originally posted by Anders Larsson@Aug 21 2007, 23:50
83 kr i månaden för att få besökarnas förtroende är väl inte så dyrt?

Nej det är ett bra pris om IP nummer ingår, Aleborg tog 125/mån för IP+SSL.
Loopia skriver att SSL ingår gratis i deras webhotell, men det tror jag inte stämmer eftersom det krävs unikt IP nr...

[yoggi2k5]

Hemmasnickrade "system" i JavaScript och liknande stoppar inte en MITM-attack... Det är SSL som gäller om man vill bättra på säkerheten.

[superhaga]

Skulle man kunna dra den slutsatsen att så fort man ska ha ett inloggningssystem eller liknande så är det SSL som gäller, allt annat är ingenting att ha?

[SimonP]

Originally posted by yoggi2k5@Aug 22 2007, 16:38
Hemmasnickrade "system" i JavaScript och liknande stoppar inte en MITM-attack... Det är SSL som gäller om man vill bättra på säkerheten.

Håller inte med dig helt, visst är SSL enkelt och bra men det finns MITM attacker mot det också, både enklare (DNS/ARP spoof) och mer avancerade (DNS/ARP spoof+giltigt cert). Man kan bygga helt säkra egna loginsystem med Javascript (eller Java) om man vill, det kräver iofs en del arbete, men det går.

I ett inloggingssystem som går över vanlig HTTP hjälper java-/javascript på klienten att skydda lösenordet, ifall nån avlyssnar får dom bara "sessionsnyckeln" som är giltig under begränsad tid.

En annan aspekt är om servern skulle vara hackad och hackern vill "samla" lösenord, då hjälper inte SSL ett skit, likaså om en elaksinnad anställd med tillgång till servern skulle få för sig saker, i dessa fall skulle en klientbaserad lösning skydda lösenorden bättre. Jag skulle tro att dom flesta grövre IT-brotten bygger på att det finns en insider på företaget som blir utsatt. Det ultimata är Java+SSL tillsammans, då börjar vi snacka riktig säkerhet, men det är en annan historia... B)

[yoggi2k5]

Man kan bygga helt säkra egna loginsystem med Javascript (eller Java) om man vill, det kräver iofs en del arbete, men det går.

Nej det kan man inte.
Det säjer ju sig självt att det inte fungerar om man måste ladda ner själva "krypterings-applikationen" över en osäker förbindelse.

[SimonP]

Originally posted by yoggi2k5@Aug 23 2007, 17:27

Nej det kan man inte.
Det säjer ju sig självt att det inte fungerar om man måste ladda ner själva "krypterings-applikationen" över en osäker förbindelse.

Nej, 100% säkra system går nog ej att fram, jag menade dock "lika säkra", sorry.
Dvs. samma styrka på kryptering och samma svaghet, MITM.
När man gått över till TLS och DNSSEC kommer iofs https-protokollet att bli bättre än vad det är idag.