Aleksejs

No savas puses šodien izmetu visus lietotājus, kas reģistrējušies pēdējā mēneša laikā un kam konta aprakstā pieminēti cialis utt...

Piesakieties pie kāda no šiem cilvēkiem:

bubu

CooLynX

laacz

Roze

vai this->... satur pareizus parametrus?

vai ca storei ir noņemtas write tiesības?

NIST ir pasludinājis par uzvarētāju Keccak algoritmu. Keccak turpmāk tiks saukts vienkārši par SHA-3.

NIST Selects Winner of Secure Hash Algorithm (SHA-3) Competition

The Keccak sponge function family

Pascal Junod: Keccak is the SHA-3 Winner

Bruce Schneier: Keccak is SHA-3: NIST has just announced that Keccak has been selected as SHA-3

Īstu programmētāju izvēle tak MenuetOS [trollface]

Gribu apgūt retāk izmantotas programmēšanas paradigmas un izprast gadījumus, kad viena paradigma pārāka par citām.

Un tajā konkrētajā DB ir tāda Tabula, ja? Un šajā Tabulā ir kolonnas ischest, x un y?

Ko atgriež, ja kā 19. rindu ieraksta:

print_r($roww);

?

un

echo("SELECT * FROM InventorySQL WHERE owner='".$row['username']."'" );

izvada normālu vaicājumu, kuru SQL vadības programmā izpildot tiek viss normāli atlasīts?

17.rindiņu pārtaisi šādu:

$sqll = mysql_query( "SELECT * FROM InventorySQL WHERE owner='".$row['username']."'" ) or die('Viss ir slikti: '. mysql_error());

ok, bet tad kāda atbilde uz jautājumu par to, vai konvertē?

Tā varētu būt. Starpbanku norēķinu standarts () definēts te:

http://www.bankasoc.lv/lv/komitejas/FiDAViSTa_apraksts.pdf

Tā ir virkne, kuras formāts definēts kā EksString (14. lpp) un ir:

0-9|A-Z|a-z|ā-ž|Ā-Ž|\s/\-\?:().,'\+\n\r

Piemēram, SEB nepieņem maksājumus, kuru apraksts neatbilst šai prasībai. Swedbank, iespējams, konvertē.

pagaidām neredzu nevinu vietu, kur kaut ko saglabātu kādā failā.

pēc tā koda beigās $v_public būtu jāsatur "---BEGIN PUBLIC KEY---" un $v_private būtu jāsatur "---BEGIN RSA PRIVATE KEY---".

O! Liels, paldies! Pašam arī kaut kur jābūt, taču neesmu meklējis.

IP piesaiste pilnīgi noteikti samazina to indivīdu kopu, kam ļauts izmantot konkrētās funkcionalitātes konkrētajā gadījumā. Problēma šeit nav faktā, ka daudzi lietotāji nāk no vienas adreses, bet gan tajā, ka eksistē lietotāji, kam sesijas laikā vairākkārt mainās IP adrese.

Šie divi raksti gan par .NET, tomēr par paroļu problēmu aprakstīts labi:

http://www.troyhunt.com/2012/06/our-password-hashing-has-no-clothes.html

http://www.troyhunt.com/2012/07/stronger-password-hashing-in-net-with.html

Par bcrypt atsauksmes labas, arī par scrypt labas. Scrypt, gan neesmu PHP vidē redzējis. Arī bcrypt var nebūt pieejams.

Ja grib izmantot standarta hešošanas algoritmus, tad labāk sāli piesaistīt ar hash_hmac().

Reiz biju uztaisījis paraugu bezsesiju autentificēšanas mehānismam, kas izmantoja vairākkārtēju hashoshanu: http://php.lv/f/topic/11116-lietotaju-autentificesana/ taču šķiet, ka paste.php.lv pazaudējusi to saturu (Ja kādu interesē, tad lūk pēdējā atrastā publikācija par šo tēmu: http://www.cse.msu.edu/~alexliu/publications/Cookie/cookie.pdf ).

Jebkurā gadījumā, bez pašas hashošanas ir vēl citi mehānismi, kā DB pusē nodrošināt paroļu aizsardzību.

Labs un gana autoritatīvs resurss:

https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet

Ā - ok.

vēl jautājums... By Default sha1 izdod hexadecimālā formātā, vai nevajag, lai izdod raw?

sha1($data,true);

?

Man kaut kā nešķiet, ka ir pareiza secība. Cik no teksta saprotu, tad secībai ir jābūt šādai:

openssl_sign(sha1(data))

bet kodā šķiet, ka ir:

sha1(openssl_sign(data))

Labāk ir pašam izgudrot un uzturēt validācijas?

Viens variants ar IN ir uzģenerēt vajadzīgo jautājumzīmīšu skaitu dinamiski.

$skaits=sizeof($masivs);

$statementmaska='SELECT * FROM tabula WHERE lauks IN ('.implode(',', array_fill(0, $skaits, '?')) .')';

Es neesmu DB guru, droši vien Gints varētu ko pateikt. Lūk iespējamie risinājumi:

http://www.javaranch.com/journal/200510/Journal200510.jsp#a2

Vajag pēc iespējas izvairīties no tādiem gadījumiem, kad tādas lietas nepieciešamas.

Šajā konkrētajā paroļu gadījumā absolūti nevajadzīga un kaitīga ir dinamiska pieprasījuma veidošanas iespēja.

ne par OOP realizējumu:

Kādēļ ierobežot parolēs atļautos izmantotos simbolus?

Un labāk būtu to visu rakstīt ar prepared statementiem un bindotiem variabļiem - tas atrisinātu gandrīz visas ar SQL injekcijām saistītās problēmas. https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet

Un paroles glabāšanas formātu/veidu vajadzētu uzlabot: https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet

private function encryptPassword($password, $salt){
  return strrev(md5($password.$salt));
}