In reply to @bkil:grin.hu
A helyes kérdés rögtön az elején, hogy honnan tudják, hogy jelszóváltoztatáskor milyen betűk voltak az előzőben?! Amennyiben bekérik újra kliens oldalon és a szerver mindig csak a hashet kapja meg, ez azt jelenti, hogy ez az ellenőrzés triviálisan kiüthető. A másik esetre nem is akarok gondolni.

In reply to@gergely:polonkai.eu
az indiai nyelvjárásokkal kevésbé vagyok képben, de biztos, hogy még mindig a mandarin a leggyakoribb? 😄

In reply to@urbalazs:grin.hu

Kérjük, adja meg új jelszavát! Az új jelszónak minimum 8 karakternek kell lennie, kötelezően tartalmaznia kell két betűt, amelyikből egy nagy legyen, valamint egy számot. Az új jelszónak legalább 5 karakterben különböznie kell az előző jelszótól.

Miután megkérdeztem az ügyfélszolgálatot, hogy miért nem jó a 64 karakteres [a-zA-Z0-9] + bővettett ASCII karakterkeszéltű jelszavam, akkor ezt a választ kaptam:

A jelszó nem lehet 40 karakternél hosszabb, Unicode karaktereket lehet használni benne. A rendszer megkülönbözteti kis és nagy betűt, az első karakter nem lehet írásjel (pl.: ! vagy ? ) Az első három karakter nem lehet ugyanaz a karakter (pl.: AAA nem megengedett). Legalább egy karakterben az új jelszónak eltérőnek kell lennie a régi jelszótól.

Az ilyeneknél sose értettem, hogy mi a fenének kellenek ezek a megkötések. Miért nem jó az, hogy

if (sha_256('ÚJ JELSZÓ BÁRMILYEN KARAKTERREL BÁRMILYEN HOSSZAN') != stored_password_hash) {
   stored_password_hash = sha_256('ÚJ JELSZÓ BÁRMILYEN KARAKTERREL BÁRMILYEN HOSSZAN');
   echo 'Sikeres jelszóváltoztatás!');
}

Opcionálisan sózással, de attól még mindegy, mit szeretnék új jelszónak.

  $pw = '<?php //' . validate_regexp('new', '[0-9a-f]{1,64}', 'missing new');

$pw = '<?php //' . validate_regexp('new', '[0-9a-f]{1,64}', 'missing new');

$pw = '<?php //' . validate_regexp('new', '[0-9a-f]{1,64}', 'missing new');

• Mi lenne ha még süti és authorizáció se lenne, hanem maga a script elérési útja (fájlneve) lenne az admin titok?

• Az admin API tudna mindent: a gyökérben mappákat létrehozni és fájlt írni, törölni. Ha egyszemélyes, nem is kell másik API. Különben a JS0 kliensben felhasználói menedzsmentet látna el (random nevű főmappát hoz nekik létre).

• GDPR miatt a felhasználóknak nem lenne neve, csak hosszú random ID-ja ami egyben szintén hozzáférési titokként funkcionálna. Ezen kívül egy felhasználó kaphatna 1-1 saját publikusan olvasható mappát (szintén random ID alapján GDPR miatt), amit ő maga időnként rotálhat is ha úgy gondolja (vagy lehetne 1 fix és 1 rotálható). A saját mappáján belül tudna fájlt írni, törölni.

• HTTP POST

• CSRF token

• user-agent

• REFERER

• kliens IP

• 1h inaktivitás

• session cookie: /, secure, httponly, GC

• kvóta

• server side salt & pepper

Deck CSS-only presentation sildes arranged on a grid with smooth panning transition, a zoomed out overview, table of contents

I've recreated an old animal guessing game that learns in the simplest way. I have yet to ask for your help when I guess wrong. Help goes something like this: What is your animal? What could I ask to tell it from a frog? I think it would be awesome if advice collected throughout the federation can be combined into one game by some kind of tree merge. Here is how I think merging new animals can work. Anyone who plays the game from a logged in origin will be prompted for new animals. This will be recorded along with the path of yes/no answers that lead to the new question. New paths will be merged with other new animals and saved into that origin's animal-guessing-game asset folder. Future versions of the game will read all of these files in order to build decision trees with multiple yes and no choices. A moderator (me?) will merge available trees and add Wikimedia Commons images as appropriate. You can play it here: http://ward.dojo.fed.wiki/animal-guessing-game.html via #Federated Wiki