Kan ni knäcka den här?

[.sun]

Håller på med en webbapplikation och ska skicka data från en sida till en annan. Eftersom infon går att avlyssna har jag försökt formatera datat så krångligt det bara går. Eftersom det är första gången jag ger mig på detta skulle jag vilja kolla hur pass smart min "kryptering" är.

 

Så, här har ni två strängar att bita i. De är båda formaterade enl samma algoritm. Det enda ni vet är att båda två innehåller texten "namn" och "lösen". Den första strängen innehåller dessutom talet 212 150 000 och den andra 153 280 500. Övriga parametrar är okända (för er).

 

Sträng 1:

70527CB86E6G16D6WERTHUOOPZ1ATA6CR7C73656EWRHJIKTY22E0714R3B718

 

Sträng 2:

B6C7SC73656REVXKJHHOQ22QE05226C807T922DFF46E6H16D6EGJNVIUTW1AA

 

Det jag skulle vilja se är hur ni tror att strängen är uppbyggd. Ange gärna ung hur lång tid det tog att knäcka (om ni lyckas vill säga). Den enda form av belöning jag kan ge är dock poäng på inlägg i den här tråden.

 

Om du lyckas knäcka koden, lägg gärna upp en modifierad variant där du ändrat på en eller flera av de givna parametrarna så kan jag analysera den och se om du gjort rätt.

[Anders N]

Sådana här tester brukar vara meningslösa. Litar du på din algoritm, så ge ut källkoden. Annars är det bara security by obscurity.

 

Har användaren på något sätt möjlighet att ändra i texten som skall skickas, och se resultatet? Jag antar att det är användarnamn och lösenord du skall skicka? Måste du skicka lösenordet? Borde du inte kunna lösa det genom att skicka ett hashat lösenord istället?

 

Ciao,

Anders

 

[.sun]

Sådana här tester brukar vara meningslösa.

 

Hur då meningslösa? Meningslösa att försöka lösa?

 

Litar du på din algoritm, så ge ut källkoden.

 

Källkoden är ju facit till hur strängen ser ut, så den kan jag inte avslöja. Men eftersom jag är grön på det här så vet jag inte hur pass säker min algoritm är. Det är inte fråga om äkta kryptering.

 

Har användaren på något sätt möjlighet att ändra i texten som skall skickas, och se resultatet?

 

Strängen skickas som POST, så användaren ser aldrig strängen. Men det finns ju tydligen program för att fånga upp sådant innan det skickas vidare - så ja, en kunnig användare kan läsa strängen och ändra den innan den skickas.

 

Jag antar att det är användarnamn och lösenord du skall skicka?

 

Bland annat. Användaren bör kunna gissa sig till att användarnamn, lösen och ett givet tal bör ingå i strängen. Övriga parametrar är dock okända för användaren.

 

Måste du skicka lösenordet?

 

Jag måste på nåt sätt verifiera användaren, ser inte att jag kan göra det utan att skicka lösenord & namn.

 

Borde du inte kunna lösa det genom att skicka ett hashat lösenord istället?

 

Hur gör man sånt? (Är som sagt helgrön på det här.)

 

[Starre]

Borde du inte kunna lösa det genom att skicka ett hashat lösenord istället?

 

Ursäkta min nyfikenhet men vad betyder hashat?

 

[Anders N]

Meningslösa att försöka lösa?

 

Ja.

 

den kan jag inte avslöja. ... Det är inte fråga om äkta kryptering.

 

Det är just sådant som gör det osäkert.

 

Användaren bör kunna gissa sig till att användarnamn, lösen och ett givet tal bör ingå i strängen.

 

Om det är användaren som matar in användarnamnet och lösenordet så är det betydligt större chans att lyckas komma på hur du har "obfuscate:at" strängen, eftersom han kan välja plaintext.

 

hashat lösenord

 

Skickar man ett hashat lösenord innebär att man inte skickar lösenordet i sig, utan en "checksumma" på lösenordet. Man kan ur checksumman inte få fram lösenordet, annat än genom att pröva alla möjliga varianter. Servern ger klienten en viss sträng, och förväntar sig en checksumma av den strängen, plus lösenordet. Ur det så kan servern kolla att det var rätt lösenord, även om det inte går att få ut lösenordet ur det som skickades.

 

Thomas Tydal har gått igenom något liknande här:

//eforum.idg.se/viewmsg.asp?EntriesId=288981#289002

 

Ciao,

Anders

 

[TicoRoman]

Ursäkta min nyfikenhet men vad betyder hashat?

Det betyder att man stoppar in ett värde i en hash-funktion, tex MD5, och får fram en kontrollsumma. Kontrollsumman består alltid av 32 tecken oavsett hur många tecken man skickar in till hash-funktionen.

 

Det blir alltid samma 32 tecken för samma värde som skickas in, även vid olika tillfällen.

 

Det finns inget, känt, sätt att gå åt andra hållet, dvs att stoppa in kontrollsumman och få tillbaka det ursprungliga värdet. Det går inte.

 

Används vid tex inloggningssystem då man inte gärna vill att lösenordet skall sparas i klartext i en cookie, osv...

 

Kanske inte världens bästa förklarning, men du förstår nog...

 

Almir - ...

____________________________________________________________

-Läser Programmet för Informatik med Systemvetenskap på MDH, Västerås.-

 

[inlägget ändrat 2002-11-12 17:35:18 av TicoRoman (Almir)]

[Anders N]

Kontrollsumman består alltid av 32 tecken oavsett hur många tecken man skickar in till hash-funktionen.

 

Ska man vara petig så är det 16 "tecken" (128 bitar). Tittar man på den som en hex-sträng är den iofs 32 tecken lång.

 

Ciao,

Anders

 

[Weyland]

Ursäkta min okunnighet, men jag testade snabbt lite hashning en gång (för att snabba upp sökningar i stora tabeller) och funderar lite på hur det ligger till med krockar i hashningar för lösenord? Är det så att två olika lösenord kanske genererar samma hash, eller är algoritmerna (typ MD5) såpass bra att inga krockar förekommer? (låter svårt/omöjligt?)

 

--

.Wey

 

..I’m the king of all time, nothing is impossible in my all powerful mind.

 

[query]

Det blir alltid samma 32 tecken för samma värde som skickas in, även vid olika tillfällen.

Det är väl dessutom så att om man skickar in två värden som liknar varandra, t.ex. "ballong" och "balkong", ska man på resultatet INTE kunna se att invärdena liknade varandra. Eftersom det är så kan man inte testa sig fram och se att ett lösen var "nästan" rätt.

 

Eller är jag ute o cyklar igen?

 

mvh,

query

_________________________________________________________

Things should be made as simple as possible, but not any simpler.

- Albert Einstein

 

 

[Anders N]

Det finns studier som visar på vissa krockar i delar av MD5-algoritmen, men inga konkreta attacker, har jag för mig.

 

Ciao,

Anders

 

[Anders N]

inte testa sig fram och se att ett lösen var "nästan" rätt

 

Precis.

 

Ciao,

Anders

 

[Glenn Larsson]

> eller är algoritmerna (typ MD5) såpass bra att inga krockar förekommer?

 

I princip ja, men så fort indata storleken överstiger blockstorleken för hash algorithmen så finns det risk för kollisioner, även chansen för att det ska hända är mikroskopiskt små. Det finns i dagsläget 1(!) känd kollision i en hash algorithm (Tror det var MD5 eller SHA) så i princip är de 99.999999999999999999...(5 dagar senare)999% säkra ifrån kollisioner.

 

Om du tittar på exempelvis SHA-1 så ser du varför du inte får samma resultat om du flippar så mycket som på 1 bit i indatan; rotationerna och de mattematiska funktionerna gör att 1 liten bit, som du puttar en snöboll åt lite olika håll & med olika styrkor på toppen av ett berg, blir till en enorm förändring, "snöboll" längst ner. Detta kallas även för "Avalance" effekt vilket är något önskvärt inom kryptografi.

 

Man brukar även hasha lösenord med exempelvis tidsstämplar eller räknare i vissa system för att skapa subgrupper (för kryptonycklar) för att öka på säkerheten några bitar.

 

Mvh

Glenn

 

[inlägget ändrat 2002-11-12 18:46:00 av Glenn]

[inlägget ändrat 2002-11-12 18:49:38 av Glenn]

[.sun]

Om fler än du tycker att det är meningslöst att försöka gissa sig till strängens innehåll så kan jag ju känna mig hyfsat säker.

 

Det är just sådant som gör det osäkert.

 

Jo, jag vet att det inte är en 100%-ig säkerhet, men det jag är nyfiken på är om det är buslätt för en användare att lista ut hur min "kryptering" är uppbyggd, eller om det är åtminstone några timmars jobb att knäcka det.

 

Om det är användaren som matar in användarnamnet och lösenordet så är det betydligt större chans att lyckas komma på hur du har "obfuscate:at" strängen, eftersom han kan välja plaintext.

 

Jodå, användaren kan pröva sig fram med olika lösenord och användarnamn, men det kommer alltid att generera i en sträng med siffror. Det jag är nyfiken på är som sagt hur pass lätt det är att lista ut vad siffrorna står för.

 

Det är data som kommer från Shockwave och skickas till en ASP-sida, så jag har (vad jag vet) inte möjlighet att använda mig av färdiga krypteringsmetoder typ MD5 el likn, utan måste bygga allt själv.

 

[Starre]

Var har du lärt dig att kryptera så här? Skulle vara spännande att lära sig.

 

[Thomas Tydal]

> Om fler än du tycker att det är

> meningslöst att försöka gissa sig

> till strängens innehåll så kan jag ju

> känna mig hyfsat säker.

 

Nej, det är ditt test som är meningslöst. Bland annat eftersom det inte är samma förutsättningar som i verkligheten. I verkligheten får man ju, som Anders påpekade, välja användarnamn och lösenord själv.

 

Vill du att jag ska testa på riktigt, så ge adressen till sidan där man matar in användarnamn och lösenord.

 

 

[Thomas Tydal]

> Var har du lärt dig att kryptera så

> här?

 

Asostotroridod Lolinondodgogrorenonsos boböcockokeror.

 

Vill du däremot ha riktig säkerhet så får du läsa Applied Cryptography av Bruce Schneier.

 

 

[Glenn Larsson]

Dodenon vovaror kokulol )

 

[inlägget ändrat 2002-11-13 02:07:30 av Glenn]

[Anp]

jag testade snabbt lite hashning en gång

Har du dragit en braja?

 

\\Anp

 

 

[.sun]

Ok, mina två strängar är för lite underlag för en bearbetning? Du vill kunna prova dig fram med olika kombinationer av användarnamn och lösenord för att få en rad olika strängar att jobba med.

 

Tyvärr existerar min "kryptering" bara som pseudokod än så länge, så jag kan inte ge dig någon adress.

 

Men jag får återkomma när jag knackat ned koden på datorn.

 

[Thomas Tydal]

> Du vill kunna prova dig fram med

> olika kombinationer av användarnamn

> och lösenord för att få en rad olika

> strängar att jobba med.

 

Tja, eftersom det blir mycket enklare då, och man kan göra så i verkligheten, och du undrar hur lätt det är att knäcka så vore det ju dumt annars.

 

Finessen är inte främst att man får fler strängar att jobba med, utan att man kan välja vilka dessa strängar ska vara.

 

 

[Mr Andersson]

Det är inte kryptering, det är teckenmanipulation.

 

[Mr Andersson]

Används SSL istället då slipper du bry dig om detta. Dessutom slipper du bygga om alltihop om någon skulle "knäcka" ditt system (dvs ta sig tid att skriva ett program som analycerar texten).

 

Rent spontant tycker jag att ditt system är ganska snarlikt Base64.

[inlägget ändrat 2002-11-13 10:00:18 av Mr Andersson]

[Mr Andersson]

Annars är det bara security by obscurity

 

Japp, det är dessutom alldeles för vanligt idag...

 

[.sun]

Servern jag ligger på har inte stöd för SSL och jag kan inte flytta. Så det är tyvärr inget alternativ.

 

Möjligtvis kan jag be att de köper in SSL, men detta projektet lär inte kunna ta den kostnaden och tiden det tar att få allt att funka.

 

[developer]

Antag att någon lyckas ta sig genom din kryptering (vilket man gör om man vill, har tid och resurser). Fråga dig själv vilken typ av data man kommer åt, hur känsligt datat är (om konkurrenter kommer åt det), och om man kan förstöra något.

 

Som utvecklare måste du göra den här typen av riskanalys och framföra den till din projektbeställare. Är han villig att ta risken att någon gör intrång eller är det värt att investera i exempelvis en SSL-lösning? Vad händer med dig om det senare visar sig att din lösning är osäker och känsligt data når konkurrenter?

 

Om du exempelvis gör ett spel i Shockwave och ska skicka in high-score, är dina transformeringar kanske fullt tillräckliga. Skickar du känsligt data låter det som du är inne på fel spår.

 

Security by obscurity är att lura sig själv. Det finns alltför många exempel på det. Jag föreslår att du skaffar någon bok om kryptografi eller datorsäkerhet som helst och bildar dig in förståelse om varför dina algoritmer inte är säkra.