finns det nån färdig funktion som liknar funktionen base64 fast med sha1 utseende dvs samma längd på strängen när den blir krypterad?.. Jag vill kryptera ID värdet så att medlemmar inte kan gissa sig fram!
Kryptering/dekryptering
21 svar · 632 visningar · startad av jboy_87
Hmm, nej det gör det inte.
Men behöver du dekryptera?
Går det inte att spara ID:t krypterat och kryptera input när du ska jämföra?
Eller jag kanske helt har missförstått vad du vill åstakomma
det e det jag inte vill göra hehe helt onödigt jag måste ju lagra Id i databasen helt onödigt! istället borde det finnas nån funktion som base64_decode och encode!
Ja tydligen ;) En sökning på php.net gav mig följande
base64_encode
base64_decode
jepp det e just det jag använder???
jag vill att krypteringen ska se ut som sha1 eller md5
Jahaaaaa! Förlåt, jag förstod inte vad du menade. Får väl skylla på att jag är trött eller nåt :p
jboy_87 skrev:
Jag vill kryptera ID värdet så att medlemmar inte kan gissa sig fram!
På vilket sett kan man gissa sig fram värdet om du använder base64?
På vilket sett kan man gissa sig fram värdet om du använder base64?
liten chans ;-)
om du krypterar endast bokstaven a så kommer det se ut så här
YQ==
vill att det ska se ut som sha1 med en bestämd längd!
men konkatenera ditt ID med slumpmässiga tecken då?
t.ex. konkatenera (10 - längden av ID) stycken slumpmässiga tecken som du sätter före/efter ID innan du krypterar. Om du vet en längd som ID:t aldrig kommer överstiga så kan du få en bestämd längd som alla krypterade ID antar.
om jag har fattat rätt så kommer inte dekrypteringen att funka eller?
Om du gör som gein beskriver och du har en fix längd på ditt ID så vet du ju hur många tecken du ska ta ut när du har dekrypterat meddelandet.
Ex: Du har fix id-längd på 3 tecken. ID: abc, du lägger till lite slump 1234567 och krypterar abc1234567. När du sedan dekrypterar så får du ju ut abc1234567 igen och eftersom du vet id-längden så plockar du bara ut de tre första tecknen ur strängen. Och vips så har du fått ut abc igen.
jboy_87 skrev:
om jag har fattat rätt så kommer inte dekrypteringen att funka eller?
Jag menar att du konkatenerar tecken som inte kan förekomma i ID:t. Om ditt ID består av bokstäver och siffror, tex. '14h3ij' så lägger du (t.ex) till '%#!!' i slutet och får '14h3ij%#!!'. Detta krypterar du och när du sedan dekrypterar tillbaka igen så läser du in ID:t från vänster tills du kommer till ett tecken som inte KAN förekomma i ett ID (eller tills strängen är slut) och därmed har du hela ID-strängen (i detta fall är det första tecknet som inte kan vara del av ID %). På så sätt får du tillbaka det ID du en gång krypterade (utan de slumpmässiga tecken som du har lagt till).
Du måste alltså bygga upp lite regler kring ditt ID. Hur långt kan det maximalt vara? Vilka tecken får förekomma i ID:t? Hur lång ska den krypterade strängen vara?
oHLLe: Längden på ID behöver inte vara fixt så länge man lägger till tecken som inte kan förekomma i ett ID.
hmm oki nu förstår jag id är egentligen användarnamnet som max kan innehålla 15 bokstäver!
jboy_87 skrev:
hmm oki nu förstår jag id är egentligen användarnamnet som max kan innehålla 15 bokstäver!
Och finns det något tecken som användarnamnet inte får innehålla? (som du kan använda för att förlänga ID:t med)
hehe jepp många tecken =).. men återkommer om hjärnan stannar!
tack ska försöka fixa det! :birp
Det är praktiskt omöjligt att kryptera information till samma längd. Detta eftersom kryptering innebär att man även kan dekryptera. För att dekryptera måste man kunna återsälla ursprungsvärdet och det kan man inte om man tar bort information från ursprungsvärdet.
SHA som du pratar är ingen krypteringsalgoritm i vanlig bemärkelse utan något som kallas för hashning, vilket är en en envägskryptering. Envägskryptering fungerar som så (enkelt förklarat) att den "förstör" strängen, alternativt lägger till tecken för att alltid uppnå ett slutresultat av en förutbestämd storlek.
Base64 är inte någon kryptering utan bara en encoding. Base64 fungerar som så att den endast "leverear" följande tecken: a-z (gemener), A-Z (versaler), 0-9, "+" och "/". Totalt 64 tecken. Detta kan vara mycket användbart när man skall skyffla information mellan olika servrar för att minska risken för att fel uppstår. Det har alltså ingenting med kryptering att göra.
För kryptering däremot finns det några alternativ. De mest vanliga är symmetrisk kryptering och assymetrisk kryptering. Enkelt förklarat är symmetrisk kryptering en typ där man använder samma nyckel för att både kryptera och dektypera. Vid assymetrisk kryptering så använder varje part en privat och en publik nyckel. Den privata nyckeln ger man aldrig ut. assymetrisk kryptering är säkrare, men i gengäld mycket långsammare.
Läs gärna swesecures artiklar i ämnet.
Förklaring av Base64
http://www.swesecure.com/?ID=ee61e315-01fa-40f5-970e-5fa642893452&IID=f540fe15-674d-4b4c-9cff-dc383d712847
Assymetrisk kryptering
http://www.swesecure.com/?ID=ee61e315-01fa-40f5-970e-5fa642893452&IID=332a5767-60ac-4f3b-8553-ce60338f7f3e
Symmetrisk kryptering
http://www.swesecure.com/?ID=ee61e315-01fa-40f5-970e-5fa642893452&IID=2295db21-6aa4-437d-9bfd-c35184c316c8
Sist men inte minst vill jag länka till "Hashalgoritmer - en introduktion"
http://www.swesecure.com/?ID=ee61e315-01fa-40f5-970e-5fa642893452&IID=52451dd6-499a-446a-9eee-6a6d25546375
Jag vet inte varför du vill kryptera användarnamnet, men som jag ser det borde det gå lika bra att använda en hashfunktion. Berätta gärna lite mer ingående vad du vill göra och varför. För om det gäller att exempelvis visa användarinformation så kan du antingen enkelt skydda det genom att man måste ha vissa rättigheter för att få tillträde. alternativt att du exponerar användarID-fältet istället för användarnamnet. ID-fältet kan då exempelvis vara av typen GUID. Då blir det svårt att gissa.
Lycka till!
SHA1 och MD5 är hashalgoritmer, dvs de går bara åt ett håll, går alltså inte att dekryptera. Du bör i stället titta på andra algoritmer som klarar av att de krypteras, oftast krävs att du definerar en nyckel i så fall och du måste då hålla den säker, annars är det ingen idé.
Brimbas svar blev lite bättre :)