[NevYn]

Originally posted by Jonas@Mar 11 2008, 22:58
Varför ens köra Base64 ??? :S

Base64 kännetecknas enkelt på att det OFTAST är 2st likamed tecken på slutet.
Vilket gör det relativt enkelt för hackern när han får tag i dina lösenord och därmed mer eller mindre har lösenordet i klartext.

EN utav nackdelen med base64 är helt enkelt att varje tecken "väger mer".

#EDIT: Notera även att Base64 inte är en hash. Base64 används främst i mailprotokollet för att skicka bilagor.

ehm, läste du hela raden, eller stannade du bara vid base64_encode?
anledningen till att jag kör base64_encode på det är för att få det i ett format som går att använda vettigt oberoende av vilket charset jag får för mig att använda i databasen..

$pwd = 'hej';
$dynsalt1 = 'hej';
$dynsalt2 = 'hej;
$pass = base64_encode(hash_hmac('sha512',$pwd,hash_hmac('sha512',$dynsalt1,$dynsalt2,true),true));
echo $pass . "<br><br>" . base64_decode($pass);

ger:

bp7TOwYAEtNUXV0jTcoJxRqQ0gBhflcqOABRP2t8VnPxwEmRuG H+Dl1BmEX2VwX6bT2I0rzHSXYv1HcajDT9Rw==

nžÓ;ÓT]]#MÊ Å?Òa~W*8Q?k|VsñÀI‘¸aþ]A˜EöWúm=ˆÒ¼ÇIv/ÔwŒ4ýG

så att de skulle få mitt lösenord i klartext genom att jag använder base64_encode ställer jag mig ytterst tveksam till...

NOTERA: fortfarande inte hela systemet, utan bara hash-lösningen som jag kör med... tänker inte skriva ut hela heller :P

[Kristoffer G]

[/QUOTE]

Originally posted by gsoc@Mar 11 2008, 23:13
Vet inte om det bara är jag men det ser ut som din applikation är väldigt sårbar för sql injections...

register.php

$in_user

Login.php

$in_user

Sen kan man nog ta $var1 i funktionen exists, men det blir ungefär samma bara det att det är på databas anslutningar man kommer åt...

Använder PDO med prepared statements på alal databaskopplingar. Anses vara det säkraste idag. Innan jobbade man mycket med mysql_real_escape_string(), addslashes() osv...

Som jag skrev i edit så har jag glömt uppdatera SQL inputen till prepared.

Man kan sen utköka de script jag skickade med mer säkerhet... men det va inte det som diskutterades här.

Läs mer här (php.net)

Prepared statements and stored procedures
Many of the more mature databases support the concept of prepared statements. What are they? You can think of them as a kind of compiled template for the SQL that you want to run, that can be customized using variable parameters. Prepared statements offer two major benefits:

The query only needs to be parsed (or prepared) once, but can be executed multiple times with the same or different parameters. When the query is prepared, the database will analyze, compile and optimize it's plan for executing the query. For complex queries this process can take up enough time that it will noticeably slow down your application if you need to repeat the same query many times with different parameters. By using a prepared statement you avoid repeating the analyze/compile/optimize cycle. In short, prepared statements use fewer resources and thus run faster.
The parameters to prepared statements don't need to be quoted; the driver handles it for you. If your application exclusively uses prepared statements, you can be sure that no SQL injection will occur. (However, if you're still building up other parts of the query based on untrusted input, you're still at risk).
Prepared statements are so useful that they are the only feature that PDO will emulate for drivers that don't support them. This ensures that you will be able to use the same data access paradigm regardless of the capabilities of the database.

[Jonas]

Ursprungligen postat av NevYn

ehm, läste du hela raden, eller stannade du bara vid base64_encode?

MMM jag läste hela raden.

$pass = base64_encode(hash_hmac,'sha512',$pwd,hash_hmac('sha512',$dynsalt1,$dynsalt2,true),true));

Där du har en konstant, klartext, variabel, function,konstant.

Ursprungligen postat av NevYn

anledningen till att jag kör base64_encode på det är för att få det i ett format som går att använda vettigt oberoende av vilket charset jag får för mig att använda i databasen..

Kvittar vilken charset du kör i MySQL, det handlar mer om vilket charset du skriver ut sidan i och vilket charset du får inputen i.
MySQL lagrar datat i det format du väljer att spara det som.

Du kan lagra UTF-8 i en Latin1 tabell utan problem, problemet dyker upp först när du skall läsa datat i någon mysql klient, men skriver du ut det på en websida så har du inga problem sålänge sidan visas i UTF-8.

Mao base64 är bara något värdelöst, räcker att datat i mysql är samma som datat du får ifrån användaren så fungerar det.

[NevYn]

Ursprungligen postat av Jonas

MMM jag läste hela raden.

$pass = base64_encode(hash_hmac,'sha512',$pwd,hash_hmac('sha512',$dynsalt1,$dynsalt2,true),true));

Där du har en konstant, klartext, variabel, function,konstant.

Kvittar vilken charset du kör i MySQL, det handlar mer om vilket charset du skriver ut sidan i och vilket charset du får inputen i.
MySQL lagrar datat i det format du väljer att spara det som.

Du kan lagra UTF-8 i en Latin1 tabell utan problem, problemet dyker upp först när du skall läsa datat i någon mysql klient, men skriver du ut det på en websida så har du inga problem sålänge sidan visas i UTF-8.

Mao base64 är bara något värdelöst, räcker att datat i mysql är samma som datat du får ifrån användaren så fungerar det.

oj, såg nu att jag hade skrivit fel..

$pass = base64_encode(hash_hmac,'sha512',$pwd,hash_hmac('sha512',$dynsalt1,$dynsalt2,true),true));

ska vara

$pass = base64_encode(hash_hmac('sha512',$pwd,hash_hmac('sha512',$dynsalt1,$dynsalt2,true),true));

hash_hmac — Generate a keyed hash value using the HMAC method
string hash_hmac ( string $algo , string $data , string $key [, bool $raw_output ] )

'sha512' => algoritmen som används
$pwd = användarens lösenord
$dynsalt1 och $dynsalt2 är helt skilda från varandra, och unika för varje användare.

men men.. du menar alltså att base64_encode() skulle sabba hela funktionen?

[Jonas]

Originally posted by NevYn@Mar 11 2008, 23:41
men men.. du menar alltså att base64_encode() skulle sabba hela funktionen?

Jag anser personligen att du slösar bara utrymme på detta i din databas, indexet blir större och databasen blir slöare.

Har du en specifik längd (md5 = 32tecken, sha1 = 40tecken osv) så hade jag satsar på en varbinary (som varchar fast för binär data) eller någon blob istället. Båda 2 är casesensitiv vilket jag misstänker är kritiskt för dig samt har inget med charset att göra.

[NevYn]

Originally posted by Jonas@Mar 11 2008, 23:52
Jag anser personligen att du slösar bara utrymme på detta i din databas, indexet blir större och databasen blir slöare.

Har du en specifik längd (md5 = 32tecken, sha1 = 40tecken osv) så hade jag satsar på en varbinary (som varchar fast för binär data) eller någon blob istället. Båda 2 är casesensitiv vilket jag misstänker är kritiskt för dig samt har inget med charset att göra.

Ah, tack för tipset! Varbinary hade jag i min iver inte alls tänkt på :P

Förutom min min blunder gällande det, vad tycker du om själva sättet att hasha på?

[SimonP]

Originally posted by Jonas
Jag anser personligen att du slösar bara utrymme på detta i din databas, indexet blir större och databasen blir slöare.

Nej, nu är du fel ute

Att Base64-encoda en hash tar mindre plats att lagra i en databas än hex-encodad hash.

Exempel:
raw MD5 = 16 tecken
base64 MD5 = ca 25 tecken
hexadecimal MD5 = 32 tecken

[NevYn]

Originally posted by SimonP@Mar 12 2008, 00:30
Nej, nu är du fel ute

Att Base64-encoda en hash tar mindre plats att lagra i en databas än hex-encodad hash.

Exempel:
raw MD5 = 16 tecken
base64 MD5 = ca 25 tecken
hexadecimal MD5 = 32 tecken

i det här fallet sparar jag på att köra det binärt istället för att köra på base64..
base64 = 88 tecken
binärt = 64 tecken

[SimonP]

Originally posted by NevYn@Mar 11 2008, 23:40
i det här fallet sparar jag på att köra det binärt istället för att köra på base64..
base64 = 88 tecken
binärt = 64 tecken

Självklart tar binärt minst lagringsutymme.

[Jonas]

Originally posted by SimonP@Mar 12 2008, 00:30
Nej, nu är du fel ute
Att Base64-encoda en hash tar mindre plats att lagra i en databas än hex-encodad hash.
Exempel:
raw MD5 = 16 tecken
base64 MD5 = ca 25 tecken
hexadecimal MD5 = 32 tecken

Nu var det så att jag syftade på att köra base64 överhuvud taget och tog upp längden på det hex-encodade som exempel.