SweClockers drabbas av dataintrång

Permalänk
Medlem
Skrivet av Broken-arrow:

Swec ser inga lösen i klartext. Det som skickas ut i mail är ett nytt lösenord. HTTPS körs där det är viktigast, alltså vid kontohantering och inloggning. Men vist vore det bra med krypterad länk till swec även i forumet.

Hur kan du säga att Sweclockers inte ser något lösenord i klartext?

Jag kan se ett par troliga scenarion:

1, Lösenordet lagras i systemet där det genereras i innan det skickas ut.
2, Mycket troligt: Mailservern som skickar mailet med nya lösenordet har en logg av alla mail.
3, Ganska troligt: Det finns loggat i en brandvägg eller annan loggningsfunktion.

Att hantera lösenord i klartext gör att Sweclockers + alla sysadmins i närheten potentiellt har access till mitt lösenord.

//karelin

Permalänk
Legendarisk
Skrivet av karelin:

Men det är ganska stor skillnad på att fiska upp ett lösenord och därmed kunna göra vad som helst med kontot utan att användaren kan skydda sig. Om du skickar en länk och någon ändrar ditt lösenord så kan Sweclockers välja att skicka en notifiering om att ditt lösenord har ändrats – och detta är vad de flesta siter med lite bättre säkerhet gör.

Det är ingen komplett lösning att skicka en notifiering om att lösenordet har ändrats eftersom att någon som kommit över kontouppgifterna och bestämmer sig för att kapa kontot även skulle byta epostadress (utan att göra det skulle ju den ursprungliga ägaren bara återställa det när han märker att kontot inte går att komma åt); meddelandet måste alltså skickas till det gamla kontot och eftersom att återställningsfunktionen är satt ur spel av ändringen på siten måste den antingen vara rent informerande (i vilket fall användaren inte kan återställa det om han inte har ändrat själv) eller inkludera en hemlighet som bara ägaren av den förra epostadressen kan känna till (i vilket fall kontot automatiskt riskerar att kapas om ägaren själv byter från en ej längre betrodd adress). För att göra bytet säkrare skulle man kunna använda tvåfaktorsautentisering för att försöka styrka att den person som gör ändringen är kontots rättmättiga ägare, men det förutsätter givetvis att det sådant system finns på plats, inte utsätter någon för risk som inte står i proportion till vad som skyddas, och att det används i tillräckligt stor utsträckning.

Skrivet av karelin:

Just nu väger diskussionen över mot att ni envist försvarar hantering av lösenord i klartext med motivationen att det inte spelar någon roll ändå pga. anledning X Y Z – DET är inte att hantera säkerhet på rätt sätt. Se kommentar nedan om lösenord i klartext.
Det handlar inte om att hitta perfekt säkerhet. Det handlar om att göra det bättre och säkrare och ge användarna en möjlighet att skydda sig själva.

  • Tycker att du får välja en något mindre anklagande ton mot @phz eftersom att han – precis som du – diskuterar frågan ur ett eget perspektiv. Vill du anklaga någon så går det bra med mig istället.

  • Vad som diskuteras är ditt inlägg om hur de temporära, slumpmässigt genererade återställningsbreven skickas och inget annat. Antagandet att mailkontot är osäkert är ditt eget, och ur det perspektivet är det oviktigt hur steg två fungerar eftersom att en person som vill ta över ditt forumkonto endast behöver steg ett. Undantaget är om någon skulle vilja avlyssna steg två, hoppas att den rättmättige ägaren inte väljer ett egen lösenord (via den HTTPS-skyddade sidan på siten), för att sedan använda det parallellt utan ägarens kännedom.

Skrivet av karelin:

Samma kommentar här som innan – låt mig som användare välja om jag vill ha två-faktors autentisering. Ta inte be beslutet åt mig.
Oftast är tvåfaktorslösningar väldigt mycket mer kostsamt än att bara ha lösenord också, så detta måste naturligtvis tas i beaktan.

Tvåfaktorsautentisering hade inte hjälpt i det aktuella fallet eftersom att de som ligger bakom attacken sannolikt inte ville komma över forumkonton; istället vill man ofta försöka använda uppgifterna från medlemsregistret för att komma över attraktivare tjänster. Tvärt om hade mer information om kontona kunnat göra databasen än mer stöldbegärlig, och därmed risken för alla användare större. Däremot hade det, som beskrivet ovan, kunnat hjälpa till vid återställning av konton.

Skrivet av karelin:

Det kanske går att hitta en mellanväg här. När jag kommer till sidan om lösenordsändring – gör DEN till HTTPS och gör det tydligt. Min kommentar om detta började för att jag var ”lat” nog att inte gå in i source-koden för sidan och se hur ni hade löst ”POST” – vilket jag hoppas att ni inte förväntar er att varje användare ska göra?

Som tidigare påpekat så är det precis så det fungerar, du har blandat ihop flera separata frågor här. Inloggningar via infällda formulär, återställning av konton, registrering, lösenordsändringar etc. görs med hela dokumentet laddat över HTTPS och en bekräftelse av vår identitet i ditt adressfält. Du kan även surfa på det viset över hela mobilsiten. Däremot är det inte möjligt att använda HTTPS över hela framsidan och när det kommer till dialogrutan har det därför blivit en kompromiss mellan bekvämlighet och säkerhet.

Det är inte meningen man ska behöva gräva i källkoden för att se hur överföringen görs, det är faktiskt inte meningen att man ska bekymra sig över det alls eftersom att det lätt kan ge en falsk känsla av säkerhet (något som tycks ha inträffat i det här fallet). Eftersom att sidan dialogrutan presenteras på skickades över HTTP kan du redan ha fallit offer för en MITM-attack och kan därför inte lita på dess innehåll eller de scripts som körs. HTTPS skyddar dig inte heller från illvilligt tredjepartsmaterial från de sidor vars överföringar har skyddats.

Sedan vore det säkrare att tvinga användaren att välja ett eget lösenord i samband med återställning (utgår man från att mailkontot är osäkert hjälper det dock inte) och jag har med på min lista att se över den processen.

Skrivet av karelin:

En av svagheterna i denna lösning är också att ni på Sweclockers faktiskt vet om lösenorden pga. Hanteringen i klartext. Att ha tillgång till era användares lösenord (minst alla era sysadmins) ger en stor potential att kunna missbruka detta. Ni skulle kunna undvika denna misstanke/risk helt om ni valde att aldrig hanterade lösenord i klartext.

Förstår inte hur (eller varför) du menar att jag skulle missbruka ditt lösenord? Särskilt inte återställningslösenorden som ju är slumpgenererade... Dels ska du inte ge varken oss eller någon annan lösenord som går att återanvända på andra tjänster alls, och dels måste du vid någon punkt kunna bekräfta din identitet för siten. Även om det t.ex. skulle prehashas på klientsidan så ger det dig inget reellt skydd mot MITM och jag skulle ju ha all tid i världen att försöka gissa lösenordet om jag nu vore intresserad av det.

Visa signatur

Abstractions all the way down.

Permalänk
Medlem
Skrivet av Biberu:

Det är ingen komplett lösning att skicka en notifiering om att lösenordet har ändrats eftersom att någon som kommit över kontouppgifterna och bestämmer sig för att kapa kontot även skulle byta epostadress (utan att göra det skulle ju den ursprungliga ägaren bara återställa det när han märker att kontot inte går att komma åt); meddelandet måste alltså skickas till det gamla kontot och eftersom att återställningsfunktionen är satt ur spel av ändringen på siten måste den antingen vara rent informerande (i vilket fall användaren inte kan återställa det om han inte har ändrat själv) eller inkludera en hemlighet som bara ägaren av den förra epostadressen kan känna till (i vilket fall kontot automatiskt riskerar att kapas om ägaren själv byter från en ej längre betrodd adress). För att göra bytet säkrare skulle man kunna använda tvåfaktorsautentisering för att försöka styrka att den person som gör ändringen är kontots rättmättiga ägare, men det förutsätter givet att det sådant system finns på plats, inte utsätter någon för risk som inte står i proportion till vad som skyddas, och att det används i tillräckligt stor utsträckning.

Jag tror jag har skrivit tre gånger nu att säkerhet kan aldrig bli perfekt och det handlar inte om att göra lösningen perfekt eller komplett. Min tråd handlar om att Sweclockers inte skall frånskriva sig ansvaret att hantera sina användares lösenord på ett oansvarigt sätt.

Skrivet av Biberu:

[ul]
[li]Tycker att du får välja en något mindre anklagande ton mot @phz eftersom att han – precis som du – diskuterar frågan ur ett eget perspektiv. Vill du anklaga någon så går det bra med mig istället.[/li]

Jag försöker använda Sweclockers för enkelhetens skull och de som hanterar varumärket och infrastrukturen bör ta åt sig.

Skrivet av Biberu:

[li]Vad som diskuteras är ditt inlägg om hur de temporära, slumpmässigt genererade återställningsbreven skickas och inget annat. Antagandet att mailkontot är osäkert är ditt eget, och ur det perspektivet är det oviktigt hur steg två fungerar eftersom att en person som vill ta över ditt konto endast behöver steg ett. Undantaget är om någon skulle vilja avlyssna steg två, hoppas att den rättmättige ägaren inte väljer ett egen lösenord (via den HTTPS-skyddade sidan på siten), för att sedan använda det parallellt utan ägarens kännedom.[/li]
[/ul]

Jag måste ha missat något här. Jag skrev att om epostkontot är komprometterat så finns det inte en smack Sweclockers kan göra. Jag utgår från att epostkontot _inte_ är komprometterat.

Skrivet av Biberu:

Tvåfaktorsautentisering hade inte hjälpt i det aktuella fallet eftersom att de som ligger bakom attacken sannolikt inte ville komma över forumkonton; istället vill man ofta försöka använda uppgifterna från medlemsregistret för att komma över attraktivare tjänster. Tvärt om hade mer information om kontona kunnat göra databasen än mer stöldbegärlig, och därmed risken för alla användare större. Däremot hade det, som beskrivet ovan, kunnat hjälpa till vid återställning av konton.

Jag har inte diskuterat attacken, jag diskuterar hur ni hanterar detta efter attacken och hur dåligt det är att hantera lösenord i klartext.

Skrivet av Biberu:

Som tidigare påpekat så är det precis så det fungerar: inloggningar via infällda formulär, återställning av konton, registrering, lösenordsändringar etc. görs med hela dokumentet laddat över HTTPS och en bekräftelse av vår identitet i ditt adressfält. Du kan även surfa på det viset över hela mobilsiten. Däremot är det inte möjligt att använda HTTPS över hela framsidan och när det kommer till dialogrutan har det därför blivit en kompromiss mellan bekvämlighet och säkerhet.

My bad. Jag ser nu att så är fallet. Kanske borde titta på ett EV-cert? 

Skrivet av Biberu:

Det är inte meningen man ska behöva gräva i källkoden för att få reda på det, det är faktiskt inte meningen att man ska bekymra sig över det alls eftersom att det lätt kan ge en falsk känsla av säkerhet (något som tycks ha inträffat i det här fallet). Eftersom att dokumentet dialogrutan presenteras på skickades över HTTP kan du redan ha fallit offer för en MITM-attack och kan därför inte lita på dess innehåll eller de scripts som körs. HTTPS skyddar dig inte heller från illvilligt tredjepartsmaterial från de sidor vars överföringar har skyddats.

Sedan vore det säkrare att tvinga användaren att välja ett eget lösenord i samband med återställning (utgår man från att mailkontot är osäkert hjälper det dock inte) och jag har med på min lista att se över den processen.

Gott.

Skrivet av Biberu:

Förstår inte hur (eller varför) du menar att jag skulle missbruka ditt lösenord? Särskilt inte återställningslösenorden som ju är slumpgenererade... Dels ska du inte ge varken oss eller någon annan lösenord som går att återanvända på andra tjänster alls, och dels måste du vid någon punkt kunna bekräfta din identitet för siten. Även om det t.ex. skulle prehashas på klientsidan så ger det dig inget reellt skydd mot MITM och vi skulle ju ha all tid i världen att försöka gissa lösenordet härifrån om vi nu vore intresserade av det.

Du ser verkligen inte skillnaden mellan att ni faktiskt har _möjligheten_ att ta fram mitt lösenord i er e-postserver mot att ni aldrig hanterar lösenord i klartext över huvud taget?

Som jag skrev innan – just nu har potentiellt alla admins på Sweclockers mitt lösenord och när någon admin slutar hos er (kanske får sparken och blir sur), vad hindrar den personen att göra en dump av databasen och ta med sig de lösenord som skickats ut? Om jag inte minns fel så har tråden redan avhandlat hashaded credentials i detalj.

En sak som skulle kunna hända är att du får _ditt_ konto kapat och någon använder dina privilegier att ta ut lösenorden, vi litar på dig men du gör ett misstag?

Jag ber om ursäkt ifall tonen varit uppskruvad.

//karelin

Permalänk
Legendarisk
Skrivet av karelin:

Jag tror jag har skrivit tre gånger nu att säkerhet kan aldrig bli perfekt och det handlar inte om att göra lösningen perfekt eller komplett. Min tråd handlar om att Sweclockers inte skall frånskriva sig ansvaret att hantera sina användares lösenord på ett oansvarigt sätt.

Hela den här diskussionen existerar därför att vi har valt att ta ansvar för det inträffade, vara öppna med vad som har hänt och informera er som berörs så att ni kan skydda era uppgifter på bästa sätt. Vi har aldrig frånskrivit oss något ansvar och om du har tolkat svar som getts i tråden på det sättet så handlar det om missförstånd.

Skrivet av karelin:

Jag försöker använda Sweclockers för enkelhetens skull och de som hanterar varumärket och infrastrukturen bör ta åt sig.

Det är det jag menar...

Skrivet av karelin:

Jag måste ha missat något här. Jag skrev att om epostkontot är komprometterat så finns det inte en smack Sweclockers kan göra. Jag utgår från att epostkontot _inte_ är komprometterat.

Premissen du själv satte är: "Får jag föreslå att ni skickar en länk där man kommer till er tjänst och får skriva sitt nya lösenord själv över HTTPS. Det är otroligt dåligt att skicka lösenord i klartext över e-post.".

Skrivet av karelin:

Jag har inte diskuterat attacken, jag diskuterar hur ni hanterar detta efter attacken och hur dåligt det är att hantera lösenord i klartext.

Det var en kommentar om tvåfaktorsautentisering i allmänhet eftersom att det lätt uppförstår missförstånd kring sådant. Återigen: de lösenord du diskuterar är de tillfälliga, slumpmässigt genererade återställningslösenorden.

Skrivet av karelin:

Du ser verkligen inte skillnaden mellan att ni faktiskt har _möjligheten_ att ta fram mitt lösenord i er e-postserver mot att ni aldrig hanterar lösenord i klartext över huvud taget?

Menar du på fullt allvar att jag skulle vara intresserad av att stjäla ditt tillfälliga, slumpmässigt genererade återställningslösenord? Det är ju absurt.

Skrivet av karelin:

Som jag skrev innan – just nu har potentiellt alla admins på Sweclockers mitt lösenord och när någon admin slutar hos er (kanske får sparken och blir sur), vad hindrar den personen att göra en dump av databasen och ta med sig de lösenord som skickats ut? Om jag inte minns fel så har tråden redan avhandlat hashaded credentials i detalj.

Till att börja med så har inte forumadministratörer tillgång till sådana uppgifter, det finns ingen orsak till att de skulle behöva det och därför finns det inte heller något system för det. Vi har inte heller möjlighet att läsa dessa tillfälliga, slumpmässigt genererade lösenord i efterhand, även om du inte litar på mig så har de inget värde för mig (de fungerar ju bara på forumet, och i de flesta fall bara tillfälligt) och därför finns det inget incitament att lägga resurser på att försöka spara dessa. Använd ett unikt lösenord för att isolera skadorna vid eventuella intrång samtidigt som du skyddar dig mot oärliga siteägare.

Skrivet av karelin:

En sak som skulle kunna hända är att du får _ditt_ konto kapat och någon använder dina privilegier att ta ut lösenorden, vi litar på dig men du gör ett misstag?

Mitt forumkonto har inte heller åtkomst till de uppgifterna. Varför skulle jag lägga resurser på att skapa ett sådant system?

Visa signatur

Abstractions all the way down.

Permalänk
Medlem
Skrivet av Biberu:

Menar du på fullt allvar att jag skulle vara intresserad av att stjäla ditt tillfälliga, slumpmässigt genererade återställningslösenord? Det är ju absurt.

Jag tycker det är synd att du väljer den tonen i din kommentar.

Jag finner ingen garanti i ditt påstående om att du aldrig skulle göra XYZ bara för att du skriver det här. I min erfarenhet handlar säkerhetsarbetet om processer, människor och teknik som stödjer processerna.

Jag kan inte annat än att konstatera att Sweclockers gjort sitt val och jag som användare får helt enkelt acceptera att ni hanterar mitt lösenord i klartext och agera därefter.

//karelin

Permalänk
Legendarisk
Skrivet av karelin:

Jag finner ingen garanti i ditt påstående om att du aldrig skulle göra XYZ bara för att du skriver det här. I min erfarenhet handlar säkerhetsarbetet om processer, människor och teknik som stödjer processerna.

Det var just därför jag rådde dig att inte ge andra viktiga uppgifter i onödan. Om du nöjer dig med att ge oss ett lösenord som endast fungerar här så är det ju fullständigt poänglöst för oss att försöka stjäla det. Varför skulle du vilja ge oss något annat, och med antagandet att ditt lösenord bara gäller här vad skulle vi har för nytta av att läsa det?

Skrivet av karelin:

Jag kan inte annat än att konstatera att Sweclockers gjort sitt val och jag som användare får helt enkelt acceptera att ni hanterar mitt lösenord i klartext och agera därefter.

Som förklarat tidigare i tråden så är det felaktigt att påstå att vi hanterar lösenord på det sättet. Vi lagrar inga lösenord i klartext, inte ens de tillfälliga som används för återställning av förlorade konton. Var snäll och avstå från att försöka vilseleda andra. Eftersom att du även utgår ifrån att du inte kan lita på vad jag säger så tror jag inte det finns mer att tillägga nu.

Visa signatur

Abstractions all the way down.

Permalänk
Medlem
Skrivet av karelin:

Hur kan du säga att Sweclockers inte ser något lösenord i klartext?

Jag kan se ett par troliga scenarion:

1, Lösenordet lagras i systemet där det genereras i innan det skickas ut.
2, Mycket troligt: Mailservern som skickar mailet med nya lösenordet har en logg av alla mail.
3, Ganska troligt: Det finns loggat i en brandvägg eller annan loggningsfunktion.

Att hantera lösenord i klartext gör att Sweclockers + alla sysadmins i närheten potentiellt har access till mitt lösenord.

//karelin

Har du ens läst hur hash fungerar? Det är endast hashat och saltat lösen som sparas. Även när du skrivet in dit lösen översätts det direkt till hash och går inte ta hashen och klistra in som lösen heller.

Kvitar vad admins gör för dom kan omöjligt se ditt riktiga lösenord. Därför vid återställning du får ett nytt lösenord på mail.

Vill man vara säker så ändrar man lösenord på swec och undviker att använda återställnings funktionen.

Du verkar antingen ha noll koll eller bara vill klaga.

Swecklockers är i alla fall mer seriösa att lösenorden ska vara krypterade än vad webbutiker är.

Skickades från m.sweclockers.com

Visa signatur

Min spel rigg:FD Define R4|VX 550W|i5 2500K|Corsair LP 4GBX2|Mammabräda P67 Extreme4|GTX 670 windforce|23tum u2312hm
Min gamla/HTPC:AMD 6000+|Ram 2GbX2|Radeon HD5770| XFX 450/nu XFX 550
Mitt bygge: ByggloggFri frakt INET:Fraktfritt sweclockers vid köp över 500kr

#Gilla inlägg som är bra & Använd citera/@"namn" vid snabbt svar

Permalänk
Medlem
Skrivet av karelin:

Jag tycker det är synd att du väljer den tonen i din kommentar.

Jag finner ingen garanti i ditt påstående om att du aldrig skulle göra XYZ bara för att du skriver det här. I min erfarenhet handlar säkerhetsarbetet om processer, människor och teknik som stödjer processerna.

Jag kan inte annat än att konstatera att Sweclockers gjort sitt val och jag som användare får helt enkelt acceptera att ni hanterar mitt lösenord i klartext och agera därefter.

//karelin

Jag förstår bara inte vad någon på SweClockers skulle göra med ett temporärt slumpgenererat lösenord i efterhand? Faran med att lösenord hanteras i klartext är väl att andra konton med samma lösenord kan bli kapade? Men lösenordet du pratar om är ju just slumpgenererat, så det kommer inte finnas några andra konton med lösenordet.

Eller har jag missuppfattat vad problemet är?

Visa signatur

Intel Core 2 Duo E4500 | Corsair XMS2 4x1024 MB | Gigabyte GA-P35-DS3 | GeCube Radeon HD 3870 | Samsung SP2504C 250 GB | Antec Sonata III | Asus VW222U

Permalänk
Medlem
Skrivet av karelin:

Jag tycker det är synd att du väljer den tonen i din kommentar.

Jag finner ingen garanti i ditt påstående om att du aldrig skulle göra XYZ bara för att du skriver det här. I min erfarenhet handlar säkerhetsarbetet om processer, människor och teknik som stödjer processerna.

Jag kan inte annat än att konstatera att Sweclockers gjort sitt val och jag som användare får helt enkelt acceptera att ni hanterar mitt lösenord i klartext och agera därefter.

//karelin

Dina argument skulle ha giltighet om Sweclockers på eget bevåg skickat ut nya lösenord till alla användare, men något sådant har åtminstone inte jag sett. Endast uppmaning att byta lösenord. Massbyte skulle förmodligen få tusentals användare att förlora kontrollen över sina konton, då folk mer eller mindre frekvent byter epost utan att uppdatera sina kontoinställningar på forum.

Ditt lösenord finns aldrig i klartext. Endast återställningslösenordet, vilket har begränsad giltighet (förmodar jag då jag inte återställt och läst mailet).

Något måste skickas till din mail om du eller någon annan begär återställningslösenord på ditt swec-konto. Om mailet snappas upp någonstans på vägen har det ingen betydelse vad det innehåller. Länk eller lösenord i klartext har ingen betydelse för en hackare.

Visa signatur

Vägra fx 3of4 Pi 1M 1.84 s Memory remapping
Minnen har ingen egen hastighet. Märkningen anger bara vilken hastighet minnena uppges klara

Permalänk
Medlem

Man behöver inte gräva in källkoden för att se om https är tillgängligt
Loggar man in genom att trycka på profil-sidan kommer man till en https-sida. Samt att man ser varför det inte är möjligt med https på siten

Permalänk
Hedersmedlem
Skrivet av karelin:

Men det är ganska stor skillnad på att fiska upp ett lösenord och därmed kunna göra vad som helst med kontot utan att användaren kan skydda sig. Om du skickar en länk och någon ändrar ditt lösenord så kan Sweclockers välja att skicka en notifiering om att ditt lösenord har ändrats – och detta är vad de flesta siter med lite bättre säkerhet gör.

I ditt antagande om att en attackerare kan "fiska upp" klartext i en användares e-postmeddelanden så utgår du ifrån att e-postkontot är kontrollerat av en attackerare.

Scenario 1:

  1. Användaren (eller någon annan) ber om att återställa ett visst kontos lösenord.

  2. Hemsidan skickar ett temporärt lösenord, och ber användaren logga i med detta nya lösenord (notera att användaren i detta fall är lika medveten om att lösenordet har ändrats).

  3. Attackeraren har kontroll över kommunikationen med e-postkontot, och kan därmed fiska upp lösenordet och ta kontroll över kontot.

Scenario 2:

  1. Användaren (eller någon annan) ber om att återställa ett visst kontos lösenord.

  2. Hemsidan skickar en länk till ett formulär på sidan där användaren kan skriva in ett nytt lösenord.

  3. Attackeraren har kontroll över kommunikationen med e-postkontot, och kan därmed fiska upp länken, gå till hemsidan, sätta ett nytt lösenord och ta kontroll över kontot.

Grundtanken i lösenordshanteringen hos egentligen alla sidor, utom möjligen de med förhöjd hotbild (typiskt om de direkt eller indirekt hanterar pengar) som därmed kräver tvåfaktorsautentisering över mobiltelefoner och andra sidokanaler, är att användarens e-postkonto är skyddat. Faller detta antagande så faller det mesta.

(Som ett sidospår så minns jag att Facebook ett tag (kanske fortfarande) bad användare skriva in sin e-postadress och lösenordet till denna så att Facebook själva skulle kunna gå in och dammsuga kontot efter e-postadresser för att koppla ihop en användare med potentiella vänner — det är något av det fundamentalt mest bakvända i säkerhetssyfte jag någonsin har sett på internet. I efterhand har jag sett att det är fler sidor som försökt med detta.)

Skrivet av karelin:

Just nu väger diskussionen över mot att ni envist försvarar hantering av lösenord i klartext med motivationen att det inte spelar någon roll ändå pga. anledning X Y Z – DET är inte att hantera säkerhet på rätt sätt. Se kommentar nedan om lösenord i klartext.
Det handlar inte om att hitta perfekt säkerhet. Det handlar om att göra det bättre och säkrare och ge användarna en möjlighet att skydda sig själva.

Vill börja med att förtydliga att jag som moderator inte är anställd av SweClockers och inte har tagit några beslut eller skrivit någon kod relaterad till SweClockers lösenordshantering, utan kan ses som en "intresserad amatör" i sammanhanget. Ifall någon har fått bilden av att jag satt mig i försvarsställning för att det skulle vara min design det handlar om så är det inte korrekt — själv ser jag detta som så självklart att jag inte förtydligat det, men hur jag ser på situationer i mitt huvud måste inte alltid vara känt för andra . Min motivering till det jag skriver är att försöka resonera kring upplevd kontra faktisk säkerhet.

Du pratar om "lösenord i klartext" — det är milsvid skillnad mellan att hantera användarens egensatta lösenord i klartext (vilket SweClockers inte gör, och vilket vore absolut horribelt) eller att skicka länkar för återställning av lösenord eller temporära inloggningar. Att ta steget att kalla även det sistnämnda "absolut horribelt" vore i mina ögon att tappa nyanser i riskbedömningen. Det är "farligt" att cykla utan hjälm och det är "farligt" att brottas med hungriga tigrar, men det ligger mycket i gradskillnaden däremellan.

Visst handlar säkerhet alltid om avvägningar, vilket jag nämnt i flera inlägg i denna tråd. Saker som behöver vägas in är dock inte bara "möjligen bättre säkerhet → kör på!", utan även vilka krav som ställs på användare, potentiell extra supporttid, ökad komplexitet i kod vilket ger ökad last för programmerare (vilket i sig ger större attackyta för attackerare), etc. Återkommer till det nedan.

Vad gäller att ge användare möjlighet till att skydda sig själva: det är ju inte som att SweClockers tvingar en användare att använda det automatgenererade lösenordet för all framtid. Snarare pekas det med hela handen och uppmanas till lösenordsbyte snarast möjligt. Metoden med att skicka länkar för lösenordsbyte över e-post är nästan allenarådande bland lågrisksidor (typiskt sidor som inte hanterar finansiell information).

Ett alternativt problem med en sådan lösning som bland annat SweClockers använder i nuläget (om jag inte missar något) är en "denial of service"-risk ifall en användares e-postadress är känd, genom att upprepat återställa dess lösenord. Jag vet inga kända fall än under sidans långa livslängd där sådant missbruk rapporterats, men det skulle kunna undvikas ifall man sänder en länk som behöver aktiveras innan lösenordet återställs. En sådan lösning skulle i stället öka tiden för en användare att återställa sitt lösenord ifall det finns anledning att tro att det kommit på vift. Kanske är man inte på en plats där man har tillgång till sitt e-postkonto — då finns det fördelar i att mer "anonymt" kunna återställa sitt lösenord liksom systemet fungerar nu. Vad som "vinner" säkerhetsmässigt är inte uppenbart att avgöra — troligen skiljer det så pass lite i praktiken att det inte bör vara en bestämmande faktor.

Skrivet av karelin:

Samma kommentar här som innan – låt mig som användare välja om jag vill ha två-faktors autentisering. Ta inte be beslutet åt mig.
Oftast är tvåfaktorslösningar väldigt mycket mer kostsamt än att bara ha lösenord också, så detta måste naturligtvis tas i beaktan.

"Valfrihet" översätts tyvärr rent krasst till större mängder programmeringstid, mer supporttid, större attackyta, etc. Det sistnämnda kan till en början låta paradoxalt, men ska inte underskattas — alltför invecklade säkerhetslösningar är troligen klart mer utsatta än enklare system. Det är en avvägning som varje sida behöver göra.

Giganter som Google, Microsoft, Facebook, Ebay, etc., har inga problem att underhålla sådana mer komplexa lösningar. Ett konto på SweClockers eller andra liknande forumsidor bör inte ses som lika attraktivt att stjäla som exempelvis ett Ebay/Tradera/Google/Microsoft/Steam/Swedbank-konto, så det är inte självklart att samma säkerhetsavvägningar gäller bara för att det handlar om "sidor på nätet" i alla fall.

Detta kopplar till just det du skrev ovan: säkerhet handlar om avvägningar, inte om att bygga Fort Knox bara för att det tekniskt (om än inte ekonomiskt eller praktiskt) vore möjligt.

Skrivet av karelin:

Det kanske går att hitta en mellanväg här. När jag kommer till sidan om lösenordsändring – gör DEN till HTTPS och gör det tydligt. Min kommentar om detta började för att jag var ”lat” nog att inte gå in i source-koden för sidan och se hur ni hade löst ”POST” – vilket jag hoppas att ni inte förväntar er att varje användare ska göra?

Sidan om lösenordsändring (och hela "Inställningar"-gränssnittet) serveras redan enbart via HTTPS. Försöker en användare gå via http://www.sweclockers.com/profil/installningar (en länk jag nyss listigt konstruerade genom att ta länken på SweClockers och ändra https till http) så omdirigeras förfrågan direkt till HTTPS — titta i adressfältet.

Den modala inloggningsrutan på framsidan skickar formulärdata över HTTPS, som jag tipsade om att man kan kontrollera via en lokal nätverkssniffer (man kan även läsa sidans källkod, men om någon verkligen ville jäklas så skulle den kunna bädda in JavaScript som busade med uppenbart innehåll). Liksom nämnts i tråden så är denna ruta en avvägning mellan bekvämlighet och säkerhet.

Återigen så har jag inte varit inblandad i beslutsprocessen bakom detta, men jag kan säga att jag en gång personligen av nyfikenhet kontrollerade att det formulär som serverades över HTTP verkligen skickades över HTTPS. Att använda en separat HTTPS-sida för inloggning och sedan skickas tillbaka hade sparat mig denna exercis. Det är snarare ett argument ur användbarhets- än säkerhetssynpunkt, men likväl ett argument. Å andra sidan hade jag kanske då i stället funderat på om HTTPS-sidan postade sitt formulär till HTTPS eller HTTP (fast jag tror alla "vanliga" webbläsare varnar om det sistnämnda sker).

Hade hela sidan kunnat ligga under HTTPS för inloggade användare hade detta kunnat undvikas, men ett antal praktiska problem med detta har behandlats tidigare i tråden.

För fullständighets skull kan man notera att det redan existerar en sådan fristående HTTPS-baserad inloggningssida via https://www.sweclockers.com/konto/logga-in?redirect=sidan-du-kom-ifrån, vilken används när man försöker nå en medlemsspecifik sida utan att vara inloggad.

Vad gäller praktiska hot så kan det nämnas att det krävs rätt mycket för att faktiskt råka ut för "man in the middle", och formulär som postar från HTTP till HTTPS är inte speciellt ovanligt att hitta ens på stora sidor (några jag noterat sedan denna diskussion startade: Webhallen och Financial Times, och Discshop blandar HTTP- och HTTPS-innehåll på inloggningssidan). För sidor utan större hotbilder (dvs inte sidor som hanterar ekonomiska data, behandlar obekväma politiska åsikter i diktaturer, etc.) så är det inte precis panikläge, även om det kan finnas utrymme för förbättring. Det tidigare resonemanget om inkludering av externt innehåll gäller dock fortfarande.

Skrivet av karelin:

Ni tvingar heller inte användaren att byta lösenord som kanske vore på sin plats. Ibland kan det dock vara bättre med lösenord som är automatgenererade och skickade i klartext än användares egna. Har ingen koll på vilka komplexitetskrav ni har på lösenorden idag.

Gällande att tvinga användaren att byta lösenord så var det vad jag menade med stycket under det du citerade: det finns i praktiken inga rimliga möjligheter att "tvinga" en användare att välja ett "bra" lösenord. Utflykt om lösenordskomplexitet och "krav" följer.

  • Minst sex tecken!

    • qwerty

    • 123456

  • Minst åtta tecken!

    • password

    • sweclockers

    • 12345678

  • Minst åtta tecken varav minst en siffra och en bokstav!

    • passw0rd

    • swecl0ckers

  • Minst åtta tecken varav minst en siffra och både stora och små bokstäver!

    • Password1

    • SweClockers1

    • Passw0rd

    • SweCl0ckers

  • Minst åtta tecken varav minst en siffra, ett specialtecken och både stora och små bokstäver!

    • Password_1

    • SweClockers_1

    • _Passw0rd

    • _SweCl0ckers

  • Minst tolv tecken varav minst en siffra, ett specialtecken och både stora och små bokstäver, lösenordet måste bytas en gång i månaden och det får inte vara samma som du redan haft!

    • Password_1505Password_1506Password_1507 → …

Även om längden och måhända komplexiteten ökar så är alla ovanstående lösenord barnsligt lätta att lista ut för en dator. Dessutom så ökar invecklade krav drastiskt risken för lösenordsåteranvändning eller "skriva upp det på en post-it-lapp på skärmen"-metoden. Man kan alltså ha

  1. gjort det betydligt bökigare för en användare att använda systemet

  2. gjort det knappt märkbart svårare för en dator att knäcka det

  3. förvärrat säkerhet/konsekvenser för användare via utökad lösenordsåteranvändning.

Därmed inte sagt att lösenordsregler är fullkomligt värdelösa i alla sammanhang, men användares irritation behöver vägas mot hotbild och nytta. Exempelvis Google tillåter inte att en användare återanvänder ett tidigare Google-lösenord (jag vet inte hur många gamla hash de sparar, men jag misstänker att de har gott om plats), vilket jag personligen inte ser som något konstigt med tanke på deras hotbild.

Vad man söker i ett starkt lösenord är hög entropi, och detta är inte trivialt att beräkna eller ens uppskatta. Faktum är att komplexa lösenordsregler, "styrkemätare" och annat ofta fatalt misslyckas med detta, och generellt bara använder lösenordslängd och antal teckenområden som mätare. Det viktigaste — slumpmässigheten — finns det ofta inte ens en teknisk möjlighet att mäta exakt (cf. [1, 2] ).

Ovanstående gör att _Passw0rd lätt "uppskattas" vara lika starkt som (L \E^@`y, trots att det förstnämnda skulle falla omedelbart vid en det minsta sofistikerad attack och det andra (kryptografiskt säkert slumpad sträng på 9 tecken ur 95 teckens urval (skrivbara tecken i ASCII-tabellen) ⇒ ≈ 59 bitars entropi) i snitt skulle ta hundratals biljarder försök att preimage-knäcka*. Även om det bara var hashat med en omgång MD5 så skulle det senare lösenordet med oclHashcat och 8 styckan Titan X enligt uppgift på programmets sida likväl ta cirka en månad dedikerad tid att hitta† (med elektricitetskostnad på cirka 2000:-‡).

SweClockers lösenordsregel är "Minst 8 tecken", med en uppmaning till användaren om att blanda olika teckenkategorier. Jag har länkat till Information Security Stack Exchange flera gånger i denna tråd — detta svar på den sidan (med marginal högst rankat, om än inte accepterat av frågeställaren) utvecklar om samma sak. Ser man mer komplexa strikta regler för lösenord än minimilängd så har man i mina ögon rätt att rynka lite på näsan. Det är möjligt att den som skapade regeln hade bra anledningar, men det är långt ifrån givet. Det blir lätt lite cargo cult över säkerhetsrelaterad design, snarare än att beslut bygger på faktiska analyser.

——
*: 95⁹ = π ⋅ 10¹⁷
†: 95⁹ hash ∕ (135 232 Mhash ∕ s) ⋅ 1 ∕ 2 = 27 dagar
‡: 95⁹ hash ∕ (135 232 Mhash ∕ s) ⋅ 1 ∕ 2 ⋅ 8 Titan X ⋅ 400 W ∕ Titan X ⋅ 1:- ∕ kWh = [Enhetskonvertingar] = 2071:-

Skrivet av karelin:

Jag måste nog säga – bullshit här. Ni kan sätta en flagga som tvingar användaren att byta lösenordet och kontrollera att det inte stämmer överens med det lösenord ni nyss skickade. Ni kan också välja att implementera komplexitetskrav på lösenorden.

Komplexitetskrav utvecklar jag om ovan.

Vad gäller att tvinga användare att byta det temporära lösenord som skickas ut så vore det tekniskt görbart utöver den uppmaning som följer i det e-postmeddelande som skickas ut. Återigen hamnar man i gränslandet mellan bekvämlighet för användare, kvantifierbar nytta ur säkerhetssynpunkt och utvecklartid (som är pengar). Vad jag menade var att även om man tvingar ett initialt lösenordsbyte så kan man inte kan hindra att en användare ändrar tillbaka till det lösenord som skickades ut (vilket inte är helt sant enligt mitt tidigare nämnda Google-exempel — men se tidigare resonemang om utvecklartid och kodkomplexitet).

"Det låter ju dumt av en användare att göra det!" — så kan man se det, men meningen var att illustrera att, visst, man kan tvinga en användare att byta lösenord när som helst (det är ju i praktiken vad en lösenordsåterställning gör), men man kan inte (möjligen utöver att åka hem till användaren och hota med stryk) tvinga en användare att skaffa ett bra, kryptografiskt säkert, globalt unikt lösenord. Användare är till syvende och sist själva ansvariga för att välja bra lösenord, så det bästa man kan göra utan att skapa irritation och fiender är i mina ögon att tipsa och försöka leda mot bra lösenordshantering.

Men ja, konceptuella poänger åsido så skulle jag åtminstone inte se det som negativt att om/när programmerartid så tillåter införa en maxlivslängd på antingen det lösenord eller den token som skickas ut vid en återställning för att "tvinga" användare att ändra lösenord. Kanske främst att dessa uppgifter bara gick att använda en gång, men kanske även med en tidsgräns på någon vettig längd. Jag har även sett lösningar som enbart tillåter åtkomst från samma klient-IP som begärde återställningen, men det känns spontant som onödig komplexitet.

Skrivet av karelin:

En av svagheterna i denna lösning är också att ni på Sweclockers faktiskt vet om lösenorden pga. Hanteringen i klartext. Att ha tillgång till era användares lösenord (minst alla era sysadmins) ger en stor potential att kunna missbruka detta. Ni skulle kunna undvika denna misstanke/risk helt om ni valde att aldrig hanterade lösenord i klartext.

Den enda information SweClockers i så fall har möjlighet att spara (och låt mig spontant säga att det låter som ytterst ointressant information att spara, men teoretiskt sett antar jag att det skulle kunna fastna i någon logg över utgående e-post) är just de av SweClockers servrar slumpade temporära lösenord (återigen: inte användarens egenvalda lösenord — det ligger oceaner av skillnad i detta) som skickas ut.

Den situation jag skulle kunna föreställa mig där detta skulle kunna ses som en möjlighet för missbruk av SweClockers administratörer är ifall användaren skulle välja att använda detta lösenord som sitt nya "standardlösenord" på externa tjänster som SweClockers administratörer inte redan har kontroll över. Detta känns i sin tur osannolikt nog att uttrycket "stor potential att kunna missbruka" känns som att det missar nyanser i riskbedömningen.

Om jag är medlem på exempelvis ett fotbollsforum så är jag ständigt i riskzonen för att administratören ("har man root så har man") skulle kunna ändra mina inlägg/addera nya inlägg i mitt namn så att det såg ut som att jag skrivit "Lionel Messi luktar kiss", varpå jag troligen snabbt skulle lämna detta forum. Det skulle däremot krävas aktiv oförsiktighet från min sida för att administratören skulle kunna använda ett liknande temporärt slumpgenererat utskickat lösenord för att attackera mig på något sätt som skulle gå utanför min interaktion just på detta forum.

Grammatik.
Visa signatur

Nu med kortare användarnamn, men fortfarande bedövande långa inlägg.

Permalänk
Medlem
Skrivet av phz:

I ditt antagande om att en attackerare kan "fiska upp" klartext i en användares e-postmeddelanden så utgår du ifrån att e-postkontot är kontrollerat av en attackerare.

Scenario 1:

  1. Användaren (eller någon annan) ber om att återställa ett visst kontos lösenord.

  2. Hemsidan skickar ett temporärt lösenord, och ber användaren logga i med detta nya lösenord (notera att användaren i detta fall är lika medveten om att lösenordet har ändrats).

  3. Attackeraren har kontroll över kommunikationen med e-postkontot, och kan därmed fiska upp lösenordet och ta kontroll över kontot.

Scenario 2:

  1. Användaren (eller någon annan) ber om att återställa ett visst kontos lösenord.

  2. Hemsidan skickar en länk till ett formulär på sidan där användaren kan skriva in ett nytt lösenord.

  3. Attackeraren har kontroll över kommunikationen med e-postkontot, och kan därmed fiska upp länken, gå till hemsidan, sätta ett nytt lösenord och ta kontroll över kontot.

Grundtanken i lösenordshanteringen hos egentligen alla sidor, utom möjligen de med förhöjd hotbild (typiskt om de direkt eller indirekt hanterar pengar) som därmed kräver tvåfaktorsautentisering över mobiltelefoner och andra sidokanaler, är att användarens e-postkonto är skyddat. Faller detta antagande så faller det mesta.

(Som ett sidospår så minns jag att Facebook ett tag (kanske fortfarande) bad användare skriva in sin e-postadress och lösenordet till denna så att Facebook själva skulle kunna gå in och dammsuga kontot efter e-postadresser för att koppla ihop en användare med potentiella vänner — det är något av det fundamentalt mest bakvända i säkerhetssyfte jag någonsin har sett på internet. I efterhand har jag sett att det är fler sidor som försökt med detta.)

Vill börja med att förtydliga att jag som moderator inte är anställd av SweClockers och inte har tagit några beslut eller skrivit någon kod relaterad till SweClockers lösenordshantering, utan kan ses som en "intresserad amatör" i sammanhanget. Ifall någon har fått bilden av att jag satt mig i försvarsställning för att det skulle vara min design det handlar om så är det inte korrekt — själv ser jag detta som så självklart att jag inte förtydligat det, men hur jag ser på situationer i mitt huvud måste inte alltid vara känt för andra . Min motivering till det jag skriver är att försöka resonera kring upplevd kontra faktisk säkerhet.

Du pratar om "lösenord i klartext" — det är milsvid skillnad mellan att hantera användarens egensatta lösenord i klartext (vilket SweClockers inte gör, och vilket vore absolut horribelt) eller att skicka länkar för återställning av lösenord eller temporära inloggningar. Att ta steget att kalla även det sistnämnda "absolut horribelt" vore i mina ögon att tappa nyanser i riskbedömningen. Det är "farligt" att cykla utan hjälm och det är "farligt" att brottas med hungriga tigrar, men det ligger mycket i gradskillnaden däremellan.

Visst handlar säkerhet alltid om avvägningar, vilket jag nämnt i flera inlägg i denna tråd. Saker som behöver vägas in är dock inte bara "möjligen bättre säkerhet → kör på!", utan även vilka krav som ställs på användare, potentiell extra supporttid, ökad komplexitet i kod vilket ger ökad last för programmerare (vilket i sig ger större attackyta för attackerare), etc. Återkommer till det nedan.

Vad gäller att ge användare möjlighet till att skydda sig själva: det är ju inte som att SweClockers tvingar en användare att använda det automatgenererade lösenordet för all framtid. Snarare pekas det med hela handen och uppmanas till lösenordsbyte snarast möjligt. Metoden med att skicka länkar för lösenordsbyte över e-post är nästan allenarådande bland lågrisksidor (typiskt sidor som inte hanterar finansiell information).

Ett alternativt problem med en sådan lösning som bland annat SweClockers använder i nuläget (om jag inte missar något) är en "denial of service"-risk ifall en användares e-postadress är känd, genom att upprepat återställa dess lösenord. Jag vet inga kända fall än under sidans långa livslängd där sådant missbruk rapporterats, men det skulle kunna undvikas ifall man sänder en länk som behöver aktiveras innan lösenordet återställs. En sådan lösning skulle i stället öka tiden för en användare att återställa sitt lösenord ifall det finns anledning att tro att det kommit på vift. Kanske är man inte på en plats där man har tillgång till sitt e-postkonto — då finns det fördelar i att mer "anonymt" kunna återställa sitt lösenord liksom systemet fungerar nu. Vad som "vinner" säkerhetsmässigt är inte uppenbart att avgöra — troligen skiljer det så pass lite i praktiken att det inte bör vara en bestämmande faktor.

"Valfrihet" översätts tyvärr rent krasst till större mängder programmeringstid, mer supporttid, större attackyta, etc. Det sistnämnda kan till en början låta paradoxalt, men ska inte underskattas — alltför invecklade säkerhetslösningar är troligen klart mer utsatta än enklare system. Det är en avvägning som varje sida behöver göra.

Giganter som Google, Microsoft, Facebook, Ebay, etc., har inga problem att underhålla sådana mer komplexa lösningar. Ett konto på SweClockers eller andra liknande forumsidor bör inte ses som lika attraktivt att stjäla som exempelvis ett Ebay/Tradera/Google/Microsoft/Steam/Swedbank-konto, så det är inte självklart att samma säkerhetsavvägningar gäller bara för att det handlar om "sidor på nätet" i alla fall.

Detta kopplar till just det du skrev ovan: säkerhet handlar om avvägningar, inte om att bygga Fort Knox bara för att det tekniskt (om än inte ekonomiskt eller praktiskt) vore möjligt.

Sidan om lösenordsändring (och hela "Inställningar"-gränssnittet) serveras redan enbart via HTTPS. Försöker en användare gå via http://www.sweclockers.com/profil/installningar (en länk jag nyss listigt konstruerade genom att ta länken på SweClockers och ändra https till http) så omdirigeras förfrågan direkt till HTTPS — titta i adressfältet.

Den modala inloggningsrutan på framsidan skickar formulärdata över HTTPS, som jag tipsade om att man kan kontrollera via en lokal nätverkssniffer (man kan även läsa sidans källkod, men om någon verkligen ville jäklas så skulle den kunna bädda in JavaScript som busade med uppenbart innehåll). Liksom nämnts i tråden så är denna ruta en avvägning mellan bekvämlighet och säkerhet.

Återigen så har jag inte varit inblandad i beslutsprocessen bakom detta, men jag kan säga att jag en gång personligen av nyfikenhet kontrollerade att det formulär som serverades över HTTP verkligen skickades över HTTPS. Att använda en separat HTTPS-sida för inloggning och sedan skickas tillbaka hade sparat mig denna exercis. Det är snarare ett argument ur användbarhets- än säkerhetssynpunkt, men likväl ett argument. Å andra sidan hade jag kanske då i stället funderat på om HTTPS-sidan postade sitt formulär till HTTPS eller HTTP (fast jag tror alla "vanliga" webbläsare varnar om det sistnämnda sker).

Hade hela sidan kunnat ligga under HTTPS för inloggade användare hade detta kunnat undvikas, men ett antal praktiska problem med detta har behandlats tidigare i tråden.

För fullständighets skull kan man notera att det redan existerar en sådan fristående HTTPS-baserad inloggningssida via https://www.sweclockers.com/konto/logga-in?redirect=sidan-du-kom-ifrån, vilken används när man försöker nå en medlemsspecifik sida utan att vara inloggad.

Vad gäller praktiska hot så kan det nämnas att det krävs rätt mycket för att faktiskt råka ut för "man in the middle", och formulär som postar från HTTP till HTTPS är inte speciellt ovanligt att hitta ens på stora sidor (några jag noterat sedan denna diskussion startade: Webhallen och Financial Times, och Discshop blandar HTTP- och HTTPS-innehåll på inloggningssidan). För sidor utan större hotbilder (dvs inte sidor som hanterar ekonomiska data, behandlar obekväma politiska åsikter i diktaturer, etc.) så är det inte precis panikläge, även om det kan finnas utrymme för förbättring. Det tidigare resonemanget om inkludering av externt innehåll gäller dock fortfarande.

Gällande att tvinga användaren att byta lösenord så var det vad jag menade med stycket under det du citerade: det finns i praktiken inga rimliga möjligheter att "tvinga" en användare att välja ett "bra" lösenord. Utflykt om lösenordskomplexitet och "krav" följer.

  • Minst sex tecken!

    • qwerty

    • 123456

  • Minst åtta tecken!

    • password

    • sweclockers

    • 12345678

  • Minst åtta tecken varav minst en siffra och en bokstav!

    • passw0rd

    • swecl0ckers

  • Minst åtta tecken varav minst en siffra och både stora och små bokstäver!

    • Password1

    • SweClockers1

    • Passw0rd

    • SweCl0ckers

  • Minst åtta tecken varav minst en siffra, ett specialtecken och både stora och små bokstäver!

    • Password_1

    • SweClockers_1

    • _Passw0rd

    • _SweCl0ckers

  • Minst tolv tecken varav minst en siffra, ett specialtecken och både stora och små bokstäver, lösenordet måste bytas en gång i månaden och det får inte vara samma som du redan haft!

    • Password_1505Password_1506Password_1507 → …

Även om längden och måhända komplexiteten ökar så är alla ovanstående lösenord barnsligt lätta att lista ut för en dator. Dessutom så ökar invecklade krav drastiskt risken för lösenordsåteranvändning eller "skriva upp det på en post-it-lapp på skärmen"-metoden. Man kan alltså ha

  1. gjort det betydligt bökigare för en användare att använda systemet

  2. gjort det knappt märkbart svårare för en dator att knäcka det

  3. förvärrat säkerhet/konsekvenser för användare via utökad lösenordsåteranvändning.

Därmed inte sagt att lösenordsregler är fullkomligt värdelösa i alla sammanhang, men användares irritation behöver vägas mot hotbild och nytta. Exempelvis Google tillåter inte att en användare återanvänder ett tidigare Google-lösenord (jag vet inte hur många gamla hash de sparar, men jag misstänker att de har gott om plats), vilket jag personligen inte ser som något konstigt med tanke på deras hotbild.

Vad man söker i ett starkt lösenord är hög entropi, och detta är inte trivialt att beräkna eller ens uppskatta. Faktum är att komplexa lösenordsregler, "styrkemätare" och annat ofta fatalt misslyckas med detta, och generellt bara använder lösenordslängd och antal teckenområden som mätare. Det viktigaste — slumpmässigheten — finns det ofta inte ens en teknisk möjlighet att mäta exakt (cf. [1, 2] ).

Ovanstående gör att _Passw0rd lätt "uppskattas" vara lika starkt som (L \E^@`y, trots att det förstnämnda skulle falla omedelbart vid en det minsta sofistikerad attack och det andra (kryptografiskt säkert slumpad sträng på 9 tecken ur 95 teckens urval (skrivbara tecken i ASCII-tabellen) ⇒ ≈ 59 bitars entropi) i snitt skulle ta hundratals biljarder försök att preimage-knäcka*. Även om det bara var hashat med en omgång MD5 så skulle det senare lösenordet med oclHashcat och 8 styckan Titan X enligt uppgift på programmets sida likväl ta cirka en månad dedikerad tid att hitta† (med elektricitetskostnad på cirka 2000:-‡).

SweClockers lösenordsregel är "Minst 8 tecken", med en uppmaning till användaren om att blanda olika teckenkategorier. Jag har länkat till Information Security Stack Exchange flera gånger i denna tråd — detta svar på den sidan (med marginal högst rankat, om än inte accepterat av frågeställaren) utvecklar om samma sak. Ser man mer komplexa strikta regler för lösenord än minimilängd så har man i mina ögon rätt att rynka lite på näsan. Det är möjligt att den som skapade regeln hade bra anledningar, men det är långt ifrån givet. Det blir lätt lite cargo cult över säkerhetsrelaterad design, snarare än att beslut bygger på faktiska analyser.

——
*: 95⁹ = π ⋅ 10¹⁷
†: 95⁹ hash ∕ (135 232 Mhash ∕ s) ⋅ 1 ∕ 2 = 27 dagar
‡: 95⁹ hash ∕ (135 232 Mhash ∕ s) ⋅ 1 ∕ 2 ⋅ 8 ⋅ 400 W ∕ Titan X ⋅ 1:- ∕ kWh = [Enhetskonvertingar] = 2071:-

Komplexitetskrav utvecklar jag om ovan.

Vad gäller att tvinga användare att byta det temporära lösenord som skickas ut så vore det tekniskt görbart utöver den uppmaning som följer i det e-postmeddelande som skickas ut. Återigen hamnar man i gränslandet mellan bekvämlighet för användare, kvantifierbar nytta ur säkerhetssynpunkt och utvecklartid (som är pengar). Vad jag menade var att även om man tvingar ett initialt lösenordsbyte så kan man inte kan hindra att en användare ändrar tillbaka till det lösenord som skickades ut (vilket inte är helt sant enligt mitt tidigare nämnda Google-exempel — men se tidigare resonemang om utvecklartid och kodkomplexitet).

"Det låter ju dumt av en användare att göra det!" — så kan man se det, men meningen var att illustrera att, visst, man kan tvinga en användare att byta lösenord när som helst (det är ju i praktiken vad en lösenordsåterställning gör), men man kan inte (möjligen utöver att åka hem till användaren och hota med stryk) tvinga en användare att skaffa ett bra, kryptografiskt säkert, globalt unikt lösenord. Användare är till syvende och sist själva ansvariga för att välja bra lösenord, så det bästa man kan göra utan att skapa irritation och fiender är i mina ögon att tipsa och försöka leda mot bra lösenordshantering.

Men ja, konceptuella poänger åsido så skulle åtminstone inte se det som negativt att om/när programmerartid så tillåter införa en maxlivslängd på antingen det lösenord eller den token som skickas ut vid en återställning för att "tvinga" användare att ändra lösenord. Kanske främst att dessa uppgifter bara gick att använda en gång, men kanske även med en tidsgräns på någon vettig längd. Jag har även sett lösningar som enbart tillåter åtkomst från samma klient-IP som begärde återställningen, men det känns spontant som onödig komplexitet.

Den enda information SweClockers i så fall har möjlighet att spara (och låt mig spontant säga att det låter som ytterst ointressant information att spara, men teoretiskt sett antar jag att det skulle kunna fastna i någon logg över utgående e-post) är just de av SweClockers servrar slumpade temporära lösenord (återigen: inte användarens egenvalda lösenord — det ligger oceaner av skillnad i detta) som skickas ut.

Den situation jag skulle kunna föreställa mig där detta skulle kunna ses som en möjlighet för missbruk av SweClockers administratörer är ifall användaren skulle välja att använda detta lösenord som sitt nya "standardlösenord" på externa tjänster som SweClockers administratörer inte redan har kontroll över. Detta känns i sin tur osannolikt nog att uttrycket "stor potential att kunna missbruka" känns som att det missar nyanser i riskbedömningen.

Om jag är medlem på exempelvis ett fotbollsforum så är jag ständigt i riskzonen för att administratören ("har man root så har man") skulle kunna ändra mina inlägg/addera nya inlägg i mitt namn så att det såg ut som att jag skrivit "Lionel Messi luktar kiss", varpå jag troligen snabbt skulle lämna detta forum. Det skulle däremot krävas aktiv oförsiktighet från min sida för att administratören skulle kunna använda ett liknande temporärt slumpgenererat utskickat lösenord för att attackera mig på något sätt som skulle gå utanför min interaktion just på detta forum.

Bra text Lite kul med google som du nämnde, den mins mitt föra lössen när jag skriver in det (men kommer så klart inte in, utan meddelar att jag hade detta lösenord för X tid sen).

Tror karelin helt enkelt inte förstår riktigt hur lösenordshanteringen fungerar, antingen det eller bara vill klaga.

Hört just det att Admins gått in och tagit bort inlägg. Speciellt sånt som går emot Admins åsikter och/eller skriver illa om "fel" företag, just för reklamintäkter (då menar jag inte detta forum utan ett annat).

Visa signatur

Min spel rigg:FD Define R4|VX 550W|i5 2500K|Corsair LP 4GBX2|Mammabräda P67 Extreme4|GTX 670 windforce|23tum u2312hm
Min gamla/HTPC:AMD 6000+|Ram 2GbX2|Radeon HD5770| XFX 450/nu XFX 550
Mitt bygge: ByggloggFri frakt INET:Fraktfritt sweclockers vid köp över 500kr

#Gilla inlägg som är bra & Använd citera/@"namn" vid snabbt svar

Permalänk
Skrivet av PowerNet:

2 faktors autentisering borde redan vara standard sedan länge på webbsidor, det höjer säkerheten rätt mycket och det är simpelt.

Nej, det är ett onödigt irritationsmoment.

Citat:

Finns inga nackdelar med 2 faktors autentisering egentligen

Förutom att det är jobbigt och onödigt.

Apropå datasäkerhet: Darkode, en stor malware-server driven av en svensk, har sprängts av polisen, 70 personer gripna: http://www.latimes.com/business/technology/la-fi-tn-darkode-t...

Permalänk
Avstängd
Skrivet av Awakeruad:

Nej, det är ett onödigt irritationsmoment.
Förutom att det är jobbigt och onödigt.

Apropå datasäkerhet: Darkode, en stor malware-server driven av en svensk, har sprängts av polisen, 70 personer gripna: http://www.latimes.com/business/technology/la-fi-tn-darkode-t...

Varför skulle det vara ett irritationsmoment?
Det är varken jobbigt eller onödigt om det byggs upp på rätt sätt, ex man skulle kunna ha (om man automatiskt är inloggad) ha så att man är det i ex 1 vecka, och därefter måste autensiera sig på nytt med både lösenord och two factor authentication.

Så det är knappast varken jobbigt eller onödigt, det märks på dig att du inte tar datasäkerhet online seriöst alls, då du inte kan förstå vitsen med en enkel two factor authentication inloggning på sidor.

Two factor authentication skulle minimera skadorna som en läckt databas får till närmst 0, om man bortser från att det fylls med SPAM mail, och de sidorna som inte stödjer two factor authentication alls.

Så jag skulle säga att two factor authentication borde redan varit standard för flera år sedan, se ex på Apple som har infört det, inga problem där, där krävs både lösenord och en kod från en betrott enhet, fungerar som det ska och är enkelt, tar inte alls lång tid att logga in för den extra säkerhet det ger.

Jag ser hellre att det tar 1-5 sek extra att logga in på en sida, än att "städa upp" allt som blir på grund av en sites databas har läckt.

Visa signatur

System: Corsair Obsidian 550D Midi Tower Svart || Corsair AX 850W PSU || Intel® Core i7-3770K Processor || ASUS P8P67-M || 2 x Intel® SSD 520 Series 180GB || Gigabyte GeForce GTX 670 2GB PhysX CUDA ||

Permalänk
Skrivet av PowerNet:

Varför skulle det vara ett irritationsmoment?

För att det är det?

Citat:

det märks på dig att du inte tar datasäkerhet online seriöst alls, då du inte kan förstå vitsen med en enkel two factor authentication inloggning på sidor.

Det är riktigt: jag är inte villig att utsätta mig för onödigt arbete. Det finns ingen anledning att ha hög säkerhet på siter som Sweclockers, Aftonbladet, eller gratismail. Det är bara säkerhetshysteri.

Citat:

Jag ser hellre att det tar 1-5 sek extra att logga in på en sida, än att "städa upp" allt som blir på grund av en sites databas har läckt.

Det gör inte jag, eftersom jag har många konto, så det blir många sekunder på en dag, och jag inte lider någon skada alls av läckor som den här på Sweclockers.

Permalänk
Avstängd
Skrivet av Awakeruad:

För att det är det?
Det är riktigt: jag är inte villig att utsätta mig för onödigt arbete. Det finns ingen anledning att ha hög säkerhet på siter som Sweclockers, Aftonbladet, eller gratismail. Det är bara säkerhetshysteri.
Det gör inte jag, eftersom jag har många konto, så det blir många sekunder på en dag, och jag inte lider någon skada alls av läckor som den här på Sweclockers.

Whut?

Sen när är det ett irritationsmoment?

Det kan knappast anses som "onödigt arbete" att lägga några sekunder extra på ett logga in på en site, mot den förhöjda säkerhet som ger rätt mycket tillbaka. Speciellt på emailkonton, där det utan tvekan ska vara two factor authentication så snart det går, vilket redan borde skett för flera år sedan.
Även på "vanliga" webbsidor borde det redan ha skett för länge sedan, men de flesta webbsidor ligger efter då det inte anses "viktigt", även om det skulle höja säkerheten enormt över hela nätet om bara ett mindre antal börjar med two factor authentication, för då blir det mindre intressant att hacka sig in i databaser för att komma åt lösenord, då de är helt oanvändbara utan den enheten som är "trusted" eller hårdvarunyckeln (ex Yubikey eller liknande).

Så two factor authentication borde införas världen runt på webbsidor, så skulle säkerheten höjas enormt då det är mycket svårare att "komma vidare" även om de har lösenordet, så kommer de ingen vart med det.

Speciellt på mail konton, vilket mer eller mindre är "nyckeln" i ens "online" liv i dagsläget, då merparten av systemen har lösenordsåterställning till mailen, och har någon annan åtkomst till mailkontot så "är man rökt" online, därför bör mailkonton inom snar framtid beläggas med obiligatorisk two factor authentication, och sedan även merparten av alla webbsidor, då det varken medför några problem, inte är något större hinder (varken rent tekniskt, eller tidsmässigt), och dessutom höjer säkerheten över hela nätet, och i längden minskar intresset av att hacka sig in på olika webbsidor, då det inte leder till något som är av nytta i alla fall då det mesta ska kräva two factor authentication.

Visa signatur

System: Corsair Obsidian 550D Midi Tower Svart || Corsair AX 850W PSU || Intel® Core i7-3770K Processor || ASUS P8P67-M || 2 x Intel® SSD 520 Series 180GB || Gigabyte GeForce GTX 670 2GB PhysX CUDA ||

Permalänk
Medlem
Skrivet av PowerNet:

Whut?

Sen när är det ett irritationsmoment?

Hurvida two factor authentication är ett irritationsmotent eller inte är ju helt och hållet personligt och subjektivt. Om Awakeruad tycker att det är ett irritationsmoment för honom så är det det.

Nu är jag själv inte emot two factor authentication utan använder det själv i flera olika sammanhang men jag tror inte att jag skulle vilja behöva använda det överallt.

Permalänk
Avstängd
Skrivet av Skyflyer:

Hurvida two factor authentication är ett irritationsmotent eller inte är ju helt och hållet personligt och subjektivt. Om Awakeruad tycker att det är ett irritationsmoment för honom så är det det.

Nu är jag själv inte emot two factor authentication utan använder det själv i flera olika sammanhang men jag tror inte att jag skulle vilja behöva använda det överallt.

Självklart är det det.

Men det beror också på hur det implementeras på sidan, görs det ex så att man är automatiskt inloggad på enheten i ex 1 vecka innan man måste logga in på nytt med både lösenord/two factor authentication så minimeras irritationen för de som tycker det är ett extra steg, men höjer ändå säkerheten för användaren (förutsatt att enheten i sig inte blir stulen, eller någon kommer in i den).

Så det beror lite på hur de implementerar funktionen på siten skulle jag säga om det blir ett irritationsmoment för de som tycker det, eller om det anses ok att autentisera sig 1 gång/vecka eller så på nytt. (Och såklart alltid kräva lösenord + two factor authentication på nya inloggningar från andra enheter).

Så det skulle kunna gå att lösa på sådant sätt så det inte anses som ett "hinder" eller "extra moment" så ofta som vid varje inloggning, just för att minimera irritationerna hos de som tycker det är krångligt eller "tar tid".

Visa signatur

System: Corsair Obsidian 550D Midi Tower Svart || Corsair AX 850W PSU || Intel® Core i7-3770K Processor || ASUS P8P67-M || 2 x Intel® SSD 520 Series 180GB || Gigabyte GeForce GTX 670 2GB PhysX CUDA ||

Permalänk

En liten allmän fråga här.

jag kan utan tvekan hålla med att two factor authentication är riktigt säker och trevligt men ser ett problem som någon annan kanske har en lösning eller ett svar på det här.

Det krävs två "enheter" för att få det att fungera, ett exempel är ju Blizzards authenticator men vad händer om den upphör att existera (går sönder, blir stulen/förlorad, den andra "enheten" blir kapad typ e-post)? I blizzards fall så är det rätt simpelt, du tar kontakt med dem och ser till att du får en ny, men under den tiden så kan du inte komma åt det kontot. Vad händer då om man har samma lösning på i princip allt, visst det blir säkert men vad händer om "enheten" går förlorad? Då är man plötsligt utesluten från allt.

Okej vissa system som banken kommer ju has sin egen "enhet" man vad gäller allt annat? Ska man ha 5+ "enheter" beroende på vad det är kopplat till för att på så vis ha ett "failsafe" ifall någon enhet går förlorad?

Visst man kan olika e-post adresser beroende på hur viktigt sakerna är (det är nog det smartare alternativet) men till en viss punkt skulle det bli otroligt irriterande att ha koll på alla "enheter" och skulle bli ännu jobbigare om "enheten" för det viktigaste går förlorad.

Vad är då en bra lösning för att hålla det så balanserat som möjligt mellan säkerhet och bekvämlighet?

Permalänk
Hedersmedlem

@Wasted Hobbit: Jag har backupkanaler i form av telefonnummer och olika extra epostkonton där det är möjligt. Har man inte tillgång till authenticatorn så är det bara att välja mail eller sms t ex.

Visa signatur

W10, Intel 5820K, Asus X99-S, Crucial DDR4 2133MHz 32GB, Sapphire 290X Tri-X, Intel 730 SSD, WD Black+Green+HGST, Silverstone FT02, Corsair AX1200, Corsair K90, Logitech MX518, Eizo 2736w, Eaton 5115 UPS. Pixel 7 pro

Permalänk
Legendarisk
Skrivet av phz:

Nuvarande lösning lägger visserligen en viss börda på användaren att faktiskt ändra sitt lösenord enligt uppmaningen i e-mailet snarare än att använda SweClockers slumpade variant som skeppats över nätet och köra på framöver.

Man måste nu välja ett eget lösenord i samband med återställning.

Visa signatur

Abstractions all the way down.

Permalänk
Skrivet av PowerNet:

Sen när är det ett irritationsmoment?

Du föreslår en lösning där jag skulle behöva plocka fram min telefon och knappa in koder på min telefon varje gång jag vill gå in på en site, och frågar hur det kan ses som ett irritationsmoment???

Citat:

Det kan knappast anses som "onödigt arbete" att lägga några sekunder extra på ett logga in på en site, mot den förhöjda säkerhet som ger rätt mycket tillbaka.

Tvåfaktor på siter som Sweclockers, Aftonbladet, eller min skräp-email ger mig ingenting tillbaka. "Tvåfaktor överallt!!!1" är precis det hysteriska säkerhetstänkande jag kritiserat i tidigare inlägg: majoriteten av konton är fullständigt oviktiga för användaren. Webfora som Sweclockers har lösenord inte för din skull, utan för att hålla spambots borta. Vad som behövs är inte överreaktion på intrång där man försöker sätta bankvalvsdörrar på varenda toalett och uthus på nätet, utan att man informerar användarna att de ska undvika att använda samma lösenord på siter de bryr sig om, framförallt siter värda pengar, som på skräp-siter de inte bryr sig om. Om man dessutom sen kan få dem att registrera ett gratis skräp-mail-konto på Gmail eller Yahoo som de använder bara när de registrerar sig på skräp-siter, så att de bara använder sitt riktiga email till konton värda pengar, vore det ännu bättre.

Permalänk
Avstängd
Skrivet av Awakeruad:

Du föreslår en lösning där jag skulle behöva plocka fram min telefon och knappa in koder på min telefon varje gång jag vill gå in på en site, och frågar hur det kan ses som ett irritationsmoment???
Tvåfaktor på siter som Sweclockers, Aftonbladet, eller min skräp-email ger mig ingenting tillbaka. "Tvåfaktor överallt!!!1" är precis det hysteriska säkerhetstänkande jag kritiserat i tidigare inlägg: majoriteten av konton är fullständigt oviktiga för användaren. Webfora som Sweclockers har lösenord inte för din skull, utan för att hålla spambots borta. Vad som behövs är inte överreaktion på intrång där man försöker sätta bankvalvsdörrar på varenda toalett och uthus på nätet, utan att man informerar användarna att de ska undvika att använda samma lösenord på siter de bryr sig om, framförallt siter värda pengar, som på skräp-siter de inte bryr sig om. Om man dessutom sen kan få dem att registrera ett gratis skräp-mail-konto på Gmail eller Yahoo som de använder bara när de registrerar sig på skräp-siter, så att de bara använder sitt riktiga email till konton värda pengar, vore det ännu bättre.

Nej, jag föreslår en lösning där man behöver autentisera med two factor authentication säg exempelvis 1 gång/vecka för att fortsätta vara inloggad (och såklart på helt nya inloggningar).

För det är ju främst nya inloggningar man vill stoppa, för det är ju de som förhindras om en databas kommer på villovägar, och lösenorden knäcks, att just nya inloggningar ska stoppas och hålla konton säkra även om lösenordet kommit på villovägar.

Och att autentisera sig 1 gång / vecka anser inte jag som ett irritationsmoment, men alla uppfattar vi ju det olika.
Jag skulle tycka att det vore en bra lösning med krav på two factor authentication på nya inloggningar, och återautentisera sig efter säg 1 vecka (eller längre om man vill det) för att fortsätta vara inloggad.

Så jag pratar inte om att ha det vid varje besök du gör på en site, utan att man exempelvis är inloggad ex 1 vecka eller 2 veckor utan att autentisera sig igen med two factor authentication, före man måste återautentisera sig.

Visa signatur

System: Corsair Obsidian 550D Midi Tower Svart || Corsair AX 850W PSU || Intel® Core i7-3770K Processor || ASUS P8P67-M || 2 x Intel® SSD 520 Series 180GB || Gigabyte GeForce GTX 670 2GB PhysX CUDA ||

Permalänk
Medlem
Skrivet av PowerNet:

Nej, jag föreslår en lösning där man behöver autentisera med two factor authentication säg exempelvis 1 gång/vecka för att fortsätta vara inloggad (och såklart på helt nya inloggningar).

För det är ju främst nya inloggningar man vill stoppa, för det är ju de som förhindras om en databas kommer på villovägar, och lösenorden knäcks, att just nya inloggningar ska stoppas och hålla konton säkra även om lösenordet kommit på villovägar.

Och att autentisera sig 1 gång / vecka anser inte jag som ett irritationsmoment, men alla uppfattar vi ju det olika.
Jag skulle tycka att det vore en bra lösning med krav på two factor authentication på nya inloggningar, och återautentisera sig efter säg 1 vecka (eller längre om man vill det) för att fortsätta vara inloggad.

Så jag pratar inte om att ha det vid varje besök du gör på en site, utan att man exempelvis är inloggad ex 1 vecka eller 2 veckor utan att autentisera sig igen med two factor authentication, före man måste återautentisera sig.

Bättre lösning är ju att låsa kontot till sin MaC/ip adress. vet andra sidor som man behöver fylla i en verifieringskod när man loggar in på steam butiken t.ex på ny ip.

Visa signatur

Min spel rigg:FD Define R4|VX 550W|i5 2500K|Corsair LP 4GBX2|Mammabräda P67 Extreme4|GTX 670 windforce|23tum u2312hm
Min gamla/HTPC:AMD 6000+|Ram 2GbX2|Radeon HD5770| XFX 450/nu XFX 550
Mitt bygge: ByggloggFri frakt INET:Fraktfritt sweclockers vid köp över 500kr

#Gilla inlägg som är bra & Använd citera/@"namn" vid snabbt svar

Permalänk

Rätt säker på att det var de små skojarna Researchgruppen som hackade er (går bara delvis in på varför jag tror det). Dom är ute efter att dels åsiktsregistrera människor och att försöka få tag på uppgifter som förhoppningsvis kan skada sina meningsmotståndare, samt vill man i bästa fall skrämmas lite.
http://www.internationalen.se/wp-content/2014/03/Researchgrup...
http://www.exponerat.net/wp-content/uploads/2014/06/Mathias-W...
(Tur dom har datorn, utan den skulle nog själva skrämselbiten få vissa... problem )

RG är alltså ett gäng vänsterextremister i regi av Robert Aschberg. SD'are är av speciellt intresse (vilka såklart återfinns på alla forum, inkl. detta). De var extremt sugna på Flashbacks databas och nån i RG erbjöd 50K ur egen ficka: https://twitter.com/Researchgruppen/status/286571517695889409

SweClockers har en stor andel SD'are, vilket de enkelt kan ha snappat upp genom att de te.x hittade pollen från 2013. 500+ SD'are är tillräckligt för att generera ett intresse från dessa.

Visa signatur

Ryzen 7 7800X3D / Gigabyte B650 Aorus Pro AX / Kingston 32GB DDR5 6400MHz CL32 FURY Renegade / RTX 3090 / Cooler Master Tempest GP27Q Gaming 27"

Permalänk
Medlem

@phz: Du skriver väldigt bra. Intressanta och genomtänkta inlägg. Du borde bli skribent

Permalänk
Hedersmedlem
Skrivet av Såa:

@phz: Du skriver väldigt bra. Intressanta och genomtänkta inlägg. Du borde bli skribent

Tackar för orden! Jag känner att jag alltid har haft lätt för språk i allmänhet och jag tycker det är roligt att fortsätta öva sig i att kunna uttrycka sig, inte minst genom att medverka i detta forum. Jag tycker att det finns mycket att hämta av att tydligt kunna förmedla tankar och omständigheter även i andra sammanhang än rent journalistiska (en "konst" som ibland kan kännas lågprioriterad när man rör sig i ingenjörsrelaterade branscher… ).

Min målbild även när jag skriver långa haranger som i denna tråd är att hela tiden försöka hålla en riktning i texten, även om enstaka inlägg kan spänna över flera relaterade ämnen. Jag uppskattar själv när det känns som att man kan hänga med i tankegången hos en författare och att texten hela tiden rör sig mot ett mål.

Sedan tror jag inte att mina texter känns lättlästa för alla likväl (speciellt inte de monsterinlägg jag skrivit i denna tråd) — det hjälper nog att ha en viss vridning åt det tekniska hållet, men då är jag ju på helt rätt plats!

Visa signatur

Nu med kortare användarnamn, men fortfarande bedövande långa inlägg.

Permalänk
Medlem

Databasen har nu börjas spridas fritt på nätet..

https://raidforums.com/Thread-sweclockers-com-Database

(moderator får gärna ta bort länken, osäker vad det rätta sättet att göra är här..)

Visa signatur

CPU: Ryzen 9 3900x Noctua NH-D14 MOBO: TUF Gaming X570-PLUS GPU: GTX 980 RAM: 32 GB 3200 MHz Chassi: R4 PSU: Corsair AX860 Hörlurar: SteelSeries 840 Mus: Logitech G502 Lightspeed V.v. nämn eller citera mig för att få svar.