ugrás a tartalomhoz

Life in a post-database world: using crypto to avoid DB writes

MadBence · 2015. Feb. 16. (H), 00.57
Hogyan használjunk kriptográfiai primitíveket adatbázisok helyett
 ■
1

Jó

Hidvégi Gábor · 2015. Feb. 16. (H), 02.10
Nagyon jó blogmark, különösen az első bekezdése fontos.
2

Összefoglalható egy-két

pythonozok · 2015. Feb. 16. (H), 09.29
Összefoglalható egy-két mondatban a tartalma? Egyszerűen nem értem, hogy miről beszél a szerző. :(
A címben úgy értem, még arról van szó, hogy adatbázisba írás helyett (úgy általában) használjunk titkosításhoz használatos függvényeket, később meg kifejezetten a userek adatainak kezeléséről ír csupa olyasmit, aminek szerintem teljesen természetesnek kell lennie, ha ilyen adatokat kezelő programot ír valaki.
De a dologhoz hozzátartozik, hogy vagy az angolom hiányos ennyire, vagy a szerző használt valami olyan "tájszólást" amit nem igazán értek.
3

A cím félrevezető. Vannak

Hidvégi Gábor · 2015. Feb. 16. (H), 09.49
A cím félrevezető. Vannak olyan szituációk, ahol érdemesebb titkosítási módszereket használni, mint adatbázisba menteni.
4

Ezt ugye nem gondolod

pythonozok · 2015. Feb. 16. (H), 10.00
Ezt ugye nem gondolod komolyan?
Az egyik titkosít, a másik tárol. Hol helyettesíti egyik a másikat?
Ezért nem értem az eredeti írást sem...
5

Az első példa arról szól,

Hidvégi Gábor · 2015. Feb. 16. (H), 10.48
Az első példa arról szól, hogy ha a felhasználó resetelni szeretné a jelszavát, akkor a meglévő adataiból készítsünk egy hash-t, és rakjuk az url végére:
HMAC256("userId=johnnysmith&expirationTime=1356156000&oldBcryptHash=$oldBcryptHash&clientIpAddress=$clientIpAddress", $mySuperSecretKey)

Ezek az adatok adottak vagy az adatbázisban vannak, ezért fölösleges új mezőben eltárolni a hash-t, mert akárhányszor legenerálod, ha a bemenő adatok nem változnak, a kimenő is ugyanaz marad.
6

Majd előszedem a gépem, ott

pythonozok · 2015. Feb. 16. (H), 11.12
Majd előszedem a gépem, ott tudok szótárazni olvasás közben, megpróbálom értelmezni, mert egyre kevésbé értem az összefüggést a cím és a tartalom között.
Amit írsz, arra mondtam, hogy nagyjából triviálisnak kellene lennie egy fejlesztő számára (azt hiszem), de ennek elég kevés köze van az adatbázisokhoz.
7

Session

vbence · 2015. Feb. 16. (H), 12.12
Tipikusan sessionben tarolando dolgokra mukodik (amiket nem kell megosztani mas userekkel). Kepzeld el, hogy az egesz sessiont a kliensoldalon tarolod (mondjuk cookieban), a kliens meg kuldozgeti a szervernek.

Ahhoz hogy ezt megtehesd egyreszt vedeni szeretned a modositastol (ne irhassa at a sessionhoz tarsitott user_id-t), es talan titkositani is (ne lassa a vasarlo melyik csoportban van).

Az elrejtest es a modositastol valo vedelmet is megoldhatod kriptoval. Az elsot egyszeru szimmetrikus kodolassal, a masodikat digitalis alairassal (hmac).

(Ps: nem olvastam a cikket).
9

Köszi, de nem ez volt a

pythonozok · 2015. Feb. 16. (H), 18.59
Köszi, de nem ez volt a gondom. A cím alapján én úgy képzeltem, valami olyan "trükköt" fog részletezni a szerző, hogy miképp lehet titkosító eljárások használatával csökkenteni az adatbázisba írásokat. Aztán beleolvasva, felszínesen átfutva rajta, úgy láttam, hogy valami biztonsági témában mélyed el, hogy hogyan lehet első jelszót küldeni, password resetet megoldani stb.
Most végigmentem a teljes cikken, amennyire az angoltudásom engedte, meg is értettem, miről ír, de az nem az, amire a címből következtettem.
8

Előszedtem, megnéztem, nekem

pythonozok · 2015. Feb. 16. (H), 18.55
Előszedtem, megnéztem, nekem nagyon olyan érzésem van, hogy a címadás... hát finoman szólva blikkesre sikerült a szerző részéről. A tartalomnak nem sok köze van hozzá, akárhonnan nézem. :)
10

Nekem erről a JWT jutott

blacksonic · 2015. Feb. 16. (H), 19.35
Nekem erről a JWT jutott eszembe.
Le tudok úgy küldeni több adatot kliensre, hogy azzal később azonosítható legyen és lejárata is van.