FAQ |
Kalender |
![]() |
#41 | |||
|
||||
Mycket flitig postare
|
Citat:
En säker hashfunktion beräknas lämna en kollision efter 2^(n/2) försök där n = antalet bits på 'slutsumman'. Så om man har en hashfunktion som ger 50 st tecken (8-bitar) blir det ca 2^200 försök, att köra igenom 2^200 värden kommer att ta miljontals år även om man använder alla jordens datorer samtidigt, det är därför man inte testar hashfunktioner genom vanliga bruteforce attacker. Ett av dom vanligaste felen när det gäller krypteringskydd är att man försöker göra en egen algoritm. Det finns nog ingen i världen som kan göra en egen säker kryptografisk funktion helt själv, 99.9% av alla officiella algoritmer som finns har blivit granskade och testade av oberoende experter under en lång period innan dom blivit accepterade som kryptografiskt säkra. Det finns redan många bra säkra algoritmer, därför är det helt onödigt att göra någon egen, och om algoritmen inte ska skydda någonting viktigt behöver man ju ingen... |
|||
![]() |
![]() |
![]() |
#42 | ||
|
|||
Har WN som tidsfördriv
|
jag vet inte du missförstod mig eller om jag missförstår det du skrivit. Med dem där 200 000 000 hasharna menar jag följande:
Bokstaven A i md5 eller sha1 blir alltid samma hash sträng. Bokstaven A i den funktion jag använder för internt bruk blir "aldrig" samma hashsträng. Det första testet jag gjorde med min var att generera 200 000 000 hash strängar i en loop, med samma ord som utgångspunkt och det blev noll dubletter. Det system jag körde på när jag genererade detta blev tjurigt som tusan när jag försökte generera fram fler hashar än så.. så helt ärligt vet jag inte hur mkt den kan generera utan att få dubletter. Men, som du även nämner så har alla officiella algoritmer testats hårt och länge innan dem blivit acepterade, vilket jag inte gjort med min. Men, det behöver inte betyda att min är sämre, inte bättre heller.. bara annorlunda ![]() Edit* Man kanske inte ens kan kalla min funktion för hash... den är väl inte Direkt baserad på någon algoritm, utan något annat också. Det går dock inte att återskapa ordet om man kör funktionen baklänges, och du behöver vissa andra parametrar för att kunna matcha en sträng mot en sträng. Edit igen* Jag är ingen expert i detta området, så jag ska kanske inte säga för mycket heller. Men, jag använder inte just denna funktionen på nätet, mest för att jag inte vill riskera att någon del ska bli public. Det är också därför jag inte visar hur en sträng ser ut. |
||
![]() |
![]() |
![]() |
#43 | ||
|
|||
Har WN som tidsfördriv
|
Avslutar mina uttalanden i denna tråd med att säga:
Använd sha1+salt Intet |
||
![]() |
![]() |
![]() |
#44 | ||
|
|||
Mycket flitig postare
|
En säkerhetslösning som baseras på att informationen om hur en "algoritm" gör för att generera en sträng förblir hemlig känns inte speciellt säker.
Hur säker är dina hashar om nån får tillgång till din källkod? ![]() |
||
![]() |
![]() |
![]() |
#45 | ||
|
|||
Har WN som tidsfördriv
|
Därför inte externt bruk. Sen är det väldigt svårt för mig att förklara hur den funkar utan att avslöja för mycket.. men jag kan säga att det inte kommer hjälpa så mycket med källkoden... svårt att förklara som sagt. Det behövs andra verktyg för att matcha saker och ting... tänk er bankdosa with a twist.
Edit* slutar kommentera här nu och låter experter på detta framföra sina åsikter. |
||
![]() |
![]() |
![]() |
#46 | ||
|
|||
Mycket flitig postare
|
Poängen med en bra algoritm är att man inte kan "avslöja för mycket". Det hela bygger ju på att även med total öppenhet som i fallet med md5 och sha1 så ska det vara lika svårt att "knäcka" hasharna. Jaja, vi lämnar det nu.
|
||
![]() |
![]() |
![]() |
#47 | |||
|
||||
Klarade millennium-buggen
|
Lite o.t men:
Det roliga med siter som försöker ÖKA säkerheten genom att införa regler runt valet av password faktiskt ger så många tips till en bruteforceknäckare att det minskar antalet möjliga kombinationer, dvs får motsatt effekt. Nog hjälper det att öka upp antalet tecken i ett password, men övriga regler + mänsklig psykologi stjälper mer än det hjälper. Ta följande regler: "Använd minst 8 tecken i ditt password": fint, nu behöver vi bara bruteforca strängar som är ca 8 till 10 tecken. I många fall är passwordet paddad med extratecken för erhålla rätt längd. "använd konstiga bokstäver" gör att folk använder minst ett q, z eller x. Bra, då minskade antalet kombinationer då vi kan först bruteforca genom att testa med dessa tecken på alla 8-10 positioner. Vi vet nu att minst ett tecken är av dessa tecken (konstiga tecken är kulturberoende btw). "Använd minst en siffra": de flesta paddar sina passwords med siffran sist så då minskade antalet kombinationer på just den teckenpositionen (7-10) ner till 10 st iställer för 255. "Blanda stora och små bokstäver": Nyttig info även detta. Sedan kan bruteforce attacken börja med att tillämpa dessa regler enligt ett dictionary så får man antagligen en träff mycket snabbare än att köra en tokslump. ... nu har vi reducerat det totala antalet möjliga ord ner till en mycket mindre mängd. ![]() |
|||
![]() |
![]() |
![]() |
#48 | |||
|
||||
Klarade millennium-buggen
|
Och för att svara på din ursprungliga fråga: ja, ditt user-id som guppar omkring i serverns minne är kopplat till en sessionscookie som webläsaren skickar med vid varje fråga till din server. Det enda sättet det går att hijacka en session skulle vara om någon annan lyckas fejka en redan aktiv cookie och skicka med denna i ett anrop (och så fungerar det väl med alla teknologier?). Detta har egentligen inget att göra med vilket data du lagrar i sessionen (dvs i serverns minne).
|
|||
![]() |
![]() |
![]() |
#49 | ||
|
|||
Supermoderator
|
Kloka ord från Robert, så sant som det är sagt.
__________________
Full-stack developer, free for smaller assignments |
||
![]() |
![]() |
![]() |
#50 | ||
|
|||
Mycket flitig postare
|
En vanligt "komplexitet-policy" i datorvärlden är ju att lösenordet ska innehålla minst tre teckentyper av fyra möjliga (gemener, versaler, siffror och specialtecken) samt vara minst 8 tecken. Jag kan inte se att det skulle hjälpa en "bruteforceknäckare", snarare avskräcka!
![]() Visst, man behöver inte testa kombinationer som inte uppfyller dessa krav, men å andra sidan så blir det väldigt tungt att knäcka lösenorden. Utan en sån policy så är det många som väljer svaga lösenord och dessa blir knäckt alldeles för fort. Den enda praktiska nackdelen är ju att folk tycker att det blir komplicerat att välja lösenord, speciellt om dom är van att ha "hej" som lösenord. |
||
![]() |
![]() |
Svara |
|
|