Korta lösenord otillräckliga i GPU-åldern

Permalänk
Medlem
Skrivet av SysGhost:

Man kan ju sedan ha samma system för flera sajter:
B0ll-sc.com-h4cker!
B0ll-tpb-h4cker!
B0ll-nordea-h4cker!
B0ll-blocket-h4cker!
B0ll-fejsbook-h4cker!
B0ll-xxx-h4cker!

Hett tips: du vill nog inte att ditt lösen ska innehålla sitens namn (eller en förkortning enkelt härledd från den), det underlättare knäckning av nyckeln nåt otroligt.

Visa signatur

|[●▪▪●]| #Lekburk#: Ryzen 3700X >-< GB-X570-AE >-< 32GB DDR4 >-< MSI RTX 3070 >-< 970 EVO 1TB SSD>--
--< Arctic Freezer 34 >-< FD Define R4 >-< Seasonic F.+ 650W >-< Acer XF270HUA >-< AOC Q2778VQE >--
#Servering#: Ryzen 1700@3,6GHz >-< Prime X470 Pro >-< 16GB DDR4 >-< GTX 1030 >-< 970 EVO 500GB SSD >--
--< Stockkylare >-< Antec P182 >-< Silver Power 600W >-< Samsung 245T |[●▪▪●]|

Permalänk
Medlem

overkill?

Jag undrar vad de definierar som säkert och hur snabbt som man faktiskt kan knäcka ett lösenord med brute force?

Det finns runt 100 tecken. Ett lösenord på 12 tecken kan då se ut på 100^12 = 10^24 sätt.

Jag vet inte hur snabbt man kan testa ett lösenord men 1 gång per FLOP låter inte helt fel?
Värdens snabbaste superdator? Cray Jaguar ligger under 2 PFLOPS = 10^15 FLOP per sekund
det tar alltså upp till 10^9 sekunder att knäcka lösenordet, minst 30 år

Vidare
världens mest energisnåla superdator enligt The Green500 List - June 2010
går på 773.38 MFLOPS/W alltså 2,782*10^15 FLOP per kWh
10^24/(2,782*10^15) ca= 3,6*10^8
att knäcka lösenordet skulle alltså kosta vid 1 kr per/kWh 360miljoner kronor.
Jag frågar för att jag är intresserad. Jag vill lära mig allt om att knäcka folks lösenord

En till sak att tänka på
20 tecken är 100^(20-12) =10^16 ggr svårare än 12 tecken var börjar overkill?

Jag skriver för övrigt det här eftersom jag egentligen borde plugga inför en tenta

källor
ASCII-tabellen (8 bitars utökad ASCII, enligt ISO 8859-1)
The Green500 List :: Environmentally Responsible Supercomputing :: The Green500 June 2010
Supercomputer - Wikipedia, the free encyclopedia

Visa signatur

Asus z68-v pro | i7 2600k | Thermalright Silver Arrow | Asus GTX 1070 Strix | Corsair Vengeance 1600MHz 16GB | Seasonic X-460 | Samsung 850 EVO 500
ASRock Z87 Extreme6 | i7 4770S | Cooler Master Hyper 212 Evo | Crucial Ballistix 16GB 1600Mhz | be quiet! E9 | Samsung 840 EVO 250 | WD RED 6+6 TB, WD Green 4+4 TB

Permalänk
Entusiast
Skrivet av MBY:

Förutsatt att lösenordshanteraren använder en välkänd algoritm och är öppen källkod samt att man som master inte väljer något retarderat, så förstår jag inte riktigt problemet?

Nja. Du har ändå egentligen bara entropi i "B0ll-" och "-h4cker!" och den entropin är som sagt samma för alla lösenord. Antagligen lurar du enkla ordboksattacker, men lurar du en kombinerad med markovkedjor? Problemet kan enkelt uttryckas så här: Extrahera ett lösenord och mellanstängen avslöjar direkt en tänkbar attack på andra sidor du besöker. Och jag föreställer mig att ett och ett kan lösenorden lätt vika sig för en ordboksattack med permutationer och markovkedjor.

Skrivet av RHWarrior:

Hett tips: du vill nog inte att ditt lösen ska innehålla sitens namn (eller en förkortning enkelt härledd från den), det underlättare knäckning av nyckeln nåt otroligt.

Mina exempel är föreklade för att kunna förmedla själva idén.
Att ha samma lösenord överallt är desto sämre.

Bäst av allt är 30-50 tecken lång, bestående av helt slumpmässiga skrivbara tecken, som ingen mänsklig iaf. kan komma ihåg, och då återkommer vi till svagheten i lösenordshanterare.
Jag gav här ett system som tar det ett steg närmare "säkerhet" än ett femstavigt a-z lösenord på 100tals sajter, och som inte behöver en lösenordshanterare. En kompromiss av lite mer säkerhet och enkelhet.

Här är ett exempellösenord, baserad på idén jag gav tidigare. men skapat utifrån ett av mina system:
#!o65rt1o5k1o1lf111rfo65tto65r1o1wpc1055aIn#%

Detta lösenord kan jag lätt komma ihåg, och är skapat enligt systsemet jag skrev om tidigare.

Visa signatur

Bästa programmen till Linux - v2.0
Linux-guide: Val av grafisk miljö. (Att välja distribution).
-
Everyone should have a SGoC in their systems (SGoC: SysGhost on a Chip)

Permalänk
Avstängd

Håller på med en liten hemsida som ska ha en medlemscommunity så då tänkta jag mig att hanteringen av lösenord kunde se ut så här...

När användaren reggar sig så tilldelas han en "lösenordsarea" som t.ex. är en nummer mellan 1000-9999. Han måste även ange ett extra lösenord som ska användas vid inloggning. Det som görs sedan är att hans riktiga lösenord sparas på plats "lösenordsarea"+extra lösenordet, alltså t.ex. 8001mittextralösenord (som hashas och så)

Tabellen ser ut så här:
Lösenordsnummerkolumn Lösenordskolumn
8001extralösenord (hashat...) lösenord (hashat...)
.....
.....
.....
.....

På användaren sparas "lösenordarean" ner men inte det extra lösenordet. När användaren sedan loggar in så får han då ange sitt lösenord plus extralösenordet. Sen kollas vilken "lösenordsarea" han tillhör och slår ihop det med extralösenordet och kollar i lösenordstabellen om lösenordet för den raden stämmer med det användaren angett.

Med detta sätt kan man inte koppla ett lösenord till användaren utan att ha användarens extralösenord som inte sparas ned i databasen så om en utomstående part skulle få tag på databasen borde användarnas uppgifter inte kunna kopplas till deras lösenord.

Och för att göra det extra krångligt tänkte jag mig att lösenordstabellen innehöll en massa lösenord som slumpats fram, t.ex. att när nån reggar sig så för den aktuella "lösenordsarean" som användaren får så skapar man säg 1000 nya lösenord som utgår från de lösenord som användaren angett.

Nån som förstår hur jag tänker och kan komma med synpunkter på om idén funkar eller om det bara är dumt att göra så?

Permalänk
Medlem
Skrivet av SysGhost:

Mina exempel är föreklade för att kunna förmedla själva idén.
Att ha samma lösenord överallt är desto sämre.
....
Här är ett exempellösenord, baserad på idén jag gav tidigare. men skapat utifrån ett av mina system:
#!o65rt1o5k1o1lf111rfo65tto65r1o1wpc1055aIn#%

Detta lösenord kan jag lätt komma ihåg, och är skapat enligt systsemet jag skrev om tidigare.

Jag gissade att det vat sånt ja, men bra att du förtydligade, det kunde kanske gett folk dåliga idéer annars.

Visa signatur

|[●▪▪●]| #Lekburk#: Ryzen 3700X >-< GB-X570-AE >-< 32GB DDR4 >-< MSI RTX 3070 >-< 970 EVO 1TB SSD>--
--< Arctic Freezer 34 >-< FD Define R4 >-< Seasonic F.+ 650W >-< Acer XF270HUA >-< AOC Q2778VQE >--
#Servering#: Ryzen 1700@3,6GHz >-< Prime X470 Pro >-< 16GB DDR4 >-< GTX 1030 >-< 970 EVO 500GB SSD >--
--< Stockkylare >-< Antec P182 >-< Silver Power 600W >-< Samsung 245T |[●▪▪●]|

Permalänk
Skrivet av Piece of Cake:

Ojdå, mitt lösenord ligger farligt nära 7-gränsen. Blir det bättre om man skriver samma sak två gånger? Alltså säg att man har "kalle" som lösenord, blir det bättre om man byter till "kallekalle" eller knäcks det lika fort?

Som de övriga har nämnt, så innebär det högre säkerhet. Mängden lösenord mellan 0-7 bokstäver är ordningen O(28^7). Att dubbla längden ger givetvis en mängdstorlek (och därmed en komplexitetsökning) på O(28^7)^2. Om man vet att det kan vara ett upprepat lösenord (vilket är ett rimligt antagande för en attackerare!), kan man prova först de O(28^7), sedan de upprepade i mängden. Detta innebär endast en ökning med en faktor 2, alltså O(2*28^7). En lösning vore då att upprepa lösenordet, men lägga till en ny bokstav i slutet.

Skrivet av MBY:

Ja, det är sant. Men det spelar föga roll. Skulle man lösa detta eller bevisa att P=NP skulle mycket kryptografi rämna. Men i praktiken spelar det inte så stor roll och få tror att P=NP. Det har rentav lanserats ett bevis nyligen att P<>NP (http://www.hpl.hp.com/personal/Vinay_Deolalikar/Papers/pnp_up... Slashdot Science Story | Claimed Proof That P != NP) men det är inte checkat och som bekant krävs det en hel del detaljgranskning innan ett bevis accepteras.

Än så länge är hash för alla praktiska tillämpningar envägsfunktioner. Eftersom de dessutom är förlustalgoritmer är de också envägs i en mer trivial kontext. Så även om P skulle visa sig vara NP mot allas förmodan så tror jag att hash fortfarande är gångbart.

Detta bevis kommer väldigt sannolikt inte att accepteras. Bevismetoden att reducera till random k-SAT är en möjlig metod för att nå ett bevis i framtiden dock, även om självaste Terrence Tao avfärdar det som osannolikt.

Visa signatur

• Sun SPARC

Permalänk
Avstängd

Jag skulle också tro att beviset är förhastat, men som sagt spelar det ingen roll i praktiskt hänseende.

Visa signatur

http://www.theatlantic.com/national/archive/2012/05/how-the-p...
"If there's a simple lesson in all of this, it's that hoaxes tend to thrive in communities which exhibit high levels of trust. But on the Internet, where identities are malleable and uncertain, we all might be well advised to err on the side of skepticism."

Permalänk
Medlem
Skrivet av muhihihaha:

Tur att man har ett redigt lösenord på 16 siffror, bokstäver och tecken som standard.
Kan rekommendera lösenord på "l33t-språket" m!ttlos3n0rds3rtypUTsoh4r4!

Ja såna lösenord är bra att koda in i någon funktion så att det blir rätt när man skriver lösenordet.
Det är bara de närmaste som kommer åt lösenordet sen.

Permalänk
Medlem
Skrivet av Andreas D:

Hjälper inte om en hackare kommer åt databasen.

Skrivet av Andreas D:

En korrekt implementation lagrar lösenorden krypterade med ett hashvärde som blir svårare att knäcka ju komplexare lösenord du använder.

Misstänker att här lagras lösenorden i klartext även om det känns pinsamt. De bör åtminstone lagras krypterade och i skilda tablespace. De blir lite svårare då, det behövs 2 databaser för att komma åt allt. Även key och forign key mellan tabellerna ska inte gå att se i klartext.

Kör en del guild war och där har för ett tag sedan många konton blivit hackade. Någon/några hade fått tag på en fil med mailkonto och tillhörande lösenord. Det gick så långt att ncsoft gick ut med en vädjan att alla bör byta lösenord snarast möjligt. Klarade mig för min del men det var många som blev av med sina konton eller fått innehållet länsat.