ugrás a tartalomhoz

Most akkor visszafejthető az MD5 vagy nem?

Szita Szilárd · 2013. Aug. 9. (P), 12.55
Videó

Itt olvastam egy cikket, hogy az MD5 nem fejthető vissza Téma
 
1

Nem

Poetro · 2013. Aug. 9. (P), 12.58
Nem visszafejthető, hanem léteznek olyan szövegek, amiknek MD5 értéke megegyezik. Ezen kívül léteznek adatbázisok, amik MD5 értékeket, és az eredeti szöveget tartalmazzák.
2

Ha így érthetőbb: léteznek

H.Z. · 2013. Aug. 9. (P), 13.10
Ha így érthetőbb:
léteznek egy és kétirányú titkosító algoritmusok.
A kétirányú (mondjuk amit a PGP vagy mondjuk a lemeztitkosító szoftverek használnak) visszafejthető a megfelelő kulccsal, hiszen pont az a célja, hogy a "címzett", el tudja olvasni a kódolt adatokat.
Az egyirányú elsősorban arra való, hogy pl. jelszavakat titkosíts vele. Ezekhez (matematikailag is bizonyítva) nem létezik olyan módszer, amivel az eredeti szöveget visszakaphatod - kivéve a brute force. Ezek ismereteim szerint aláírás készítésre, jelszavak kódolására alkalmasak. (lásd még "hash"!)

Az md5 "visszafejthető", de csak az említett brute force eljárással, ami azt jelenti, hogy gyakorlatilag végigpróbálsz minden lehetséges stringet MD5-tel kódolva, hogy azonos eredményt kapsz-e. Másik általam ismert változat az ú.n. szivárványtábla módszer, ami gyakorlatilag azt jelenti, hogy többé-kevésbé ismert jelszavakra előre legenerálták valamikor az MD5 hash-t és csak végig kell nézni a táblázatot, van-e azonosság? Ha van, akkor nyertél, ha nincs, akkor goto 1, brute force.
Ezek ellen a szivárványtáblák ellen véd valamennyire az ú.n. sózás.

De ha jók az emlékeim, az MD5-tel az a baj, hogy a grafikus kártyák párhuzamos feldolgozását kihasználva, nagyon hamar törhetőek brute force segítségével is.

------------
Ha hülyeséget írtam, javítsatok ki! Korábban is hajlamos voltam ilyesmire, de ehhez a témához nagyon nem értek, csak a hónapokkal ezelőtt összeolvasott emlékeim alapján írtam.
15

"Ezekhez (matematikailag is

tgr · 2013. Aug. 10. (Szo), 20.17
"Ezekhez (matematikailag is bizonyítva) nem létezik olyan módszer, amivel az eredeti szöveget visszakaphatod - kivéve a brute force."

Ha a potenciális bemenetek száma nagyobb, mint az md5 kimenetek száma, akkor nyilván nem létezik olyan módszer, amivel az eredeti szöveget visszakapod (brute force-szal sem). Ha kisebb (jelszavak esetén ez pl. azt jelenti, hogy 25 karakternél rövidebb alfanumerikus jelszót keresünk), akkor elenyészően kevés kivételt leszámítva nem lesznek ütközések, és brute force-szal elvileg visszanyerhető a bemenet; a gyakorlatban tizenpár karakter felett a brute force már nem realusztikus.

Semmiféle matematikai bizonyítás nincs arra, hogy ne lenne a brute force-nál sokkal hatékonyabb módszer a bemenet visszafejtésére; egyszerűen nem ismerünk ilyet.
16

Hát ennek utána fogok nézni.

H.Z. · 2013. Aug. 10. (Szo), 20.49
Hát ennek utána fogok nézni. Az egyetlen, amiben úgy 99%-ig biztos voltam, hogy az egyirányúnak nevezett algoritmusok esetében matematikai úton is bizonyították, hogy nem lehet visszafejteni a kódból az eredeti szöveget.
Ahogy itt valaki emlegette a maradékos osztás maradékából nem lehet megtudni a másik két tagot. Valami ilyesmi rémlik, de vagy tíz éve olvasgattam e témában, szóval akár igazad is lehet.
18

Ha a maradékos példánál

MadBence · 2013. Aug. 10. (Szo), 23.23
Ha a maradékos példánál maradunk (mondjuk megint a 7-es maradék):
"25 karakternél rövidebb alfanumerikus jelszót keresünk" = a bemenet pl 0 és 10 között lehet.
Belátható, hogy viszonylag kevés ütközés lesz (4 db), így pl ha tudjuk, hogy az eredmény 4, akkor a bemenet biztosan 4 volt. MD5-nél annyival bonyolultabb a dolog, hogy csak valószínűleg fogjuk tudni a bemenetet megmondani, hiszen ahogy tgr írta: "25 karakter alatt elenyészően kevés ütközés lesz", tehát nagyon valószínű, hogy megtaláltuk az eredeti bemenetet (és nem egy olyan bemenetet, ami csak véletlenül ugyanazt a kimenetet adja).
3

Gondold végig

kuka · 2013. Aug. 9. (P), 13.14
Gondold végig logikusan.

Albert Einstein – A speciális és általános relativitás elmélete.pdf MD5 ellenőrzőösszege 335e4e8dc230a84e2aaf4236e5270cdf.

Szerinted ebből vissza lehet fejteni a 40Mb-os dokumentumot?
4

A tisztánlátás kedvéért

MadBence · 2013. Aug. 9. (P), 19.16
Az md5 egy hash függvény (magyarul hasító függvény). A legegyszerűbb hash függvény a h(x)=x mod k (maradékos osztás), pl ha k=7, akkor h(1)=1,h(2)=2,...,h(6)=6,h(7)=0,h(8)=1,..... Ha tudod, hogy egy számnak a maradéka 7-tel osztva 3, attól nem leszel sokkal okosabb, hiszen nem tudod megmondani, mi volt az eredeti szám. Viszont könnyen tudsz olyan számokat mondani, ami 7-tel osztva 3-at ad maradékul.
Ugyanez a probléma az MD5-tel is, ha ismert a kimenete (azaz a hash értéke), akkor relatíve gyorsan tudsz olyan bemenetet generálni, ami ugyanazt a kimenetet adja. Így az eredeti bemenet ismerete nélkül meg lehet kerülni a rendszert.

(nem, nem fejthető vissza)
5

Igen is meg nem is

astyu · 2013. Aug. 9. (P), 19.41
A helyzet az, hogy mivel az md5 hossza mindig ugyanannyi, több dologból is ugyanazt a karakterláncot generálja (ugye sokkal többféle lehet az amiből generál mint az amit generál).

Visszafejteni tehát igazából nem tudod, legfeljebb tudsz találni valamit, amihez ugyanazt generálja mint amit te szeretnél visszafejteni, egy ún. ütközést (de sosem lehetsz benne biztos, hogy tényleg az volt).

Persze ha tudod, hogy jelszóból lett generálva és azt kapod, hogy "majom123", akkor valószínű, hogy tényleg az volt az eredeti. De még ha nem is vagy biztos benne, akkor is tudod használni azokon a helyeken, ahol a tiszta md5 alapján ellenőriznek.

(Viszont ha egy másik oldalon mondjuk sha1 van md5 helyett, vagy md5(jelszó+"salt") az ellenőrzés, ott nem fog működni az amit találtál ha az nem az igazi, tehát pl. a gmail fiókja biztonságban marad.)
6

Kicsit talán off a kérdésem.

tihi · 2013. Aug. 9. (P), 20.01
Kicsit talán off a kérdésem.
Van az említett
md5(jelszó+"salt")
ellenőrzés. Ha vissza lehet "fejteni" az md5 -öt, akkor pl több ellopott md5 jelszó esetén visszafejthető a salt is? Pl visszafejtés után a jelszavak: majom123$sdasd$ vagy jelszo123$sdasd$ akkor a só vélhetően $sdasd$. Lehet butaság. Mondjuk Én mindig a beadott jelszó egy részét felhasználva generálom a sót.
7

A brute force ellen mindenképp véd a só

astyu · 2013. Aug. 9. (P), 20.10
A lényeg igazából a tárgyban van, tehát ha elég hosszú a salt, akkor az igazi jelszót védi a brute force ellen. Egy 5-6 karakteres jelszót lehet erőből is, de ha hozzácsapsz egy plusz 15-20 karaktert, akkor jóval nehezebben fogod tudni megkapni a sózott jelszót => nem lesz miből kikövetkeztetned a só értékét.
8

Nem

MadBence · 2013. Aug. 9. (P), 20.33
A só nem a brute force ellen véd (és nem is a só értékét kell kitalálni, ha megvan a hash, feltételezhetően a salt is rendelkezésre áll), hanem a szivárványtáblák ellen: olyan bemenetet könnyű találni, ami a megadott hasht adja, de olyan bemenetet, ami a meghatározott saltot tartalmazza, azt már nehezebben (bár ez is egy gyenge pont).
10

Kiegészítésképp

astyu · 2013. Aug. 9. (P), 20.54
Teljesen igaz amit mondasz.

Viszont kéegészítésképp, ugye mivel az md5 elég gyorsan számolható, a só ismeretében nem telik lehetetlenül sok időbe egy saját táblát generálni. Ezért érdemes esetleg minden jelszóhoz külön sót generálni amit vele együtt el lehet tárolni az adatbázisban.

Ha minden jelszóhoz más-más só tartozik, akkor mindegyiket külön kell brute force-olni, nem lehet egy táblából kinézni az egész adatbázist.
(Azt ugyebár - a fentebb említett módon - a legtöbb esetben tényleg lehet feltételezni, hogy ha megvan a hash, akkor megvan a só is, tehát nem sokkat árt a biztonságnak ha egymás mellett tároljuk őket rögtön.)
11

Ez is igaz, de

Pepita · 2013. Aug. 10. (Szo), 11.54
nem kell a sót feltétlenül tárolni.
Generálhatod egy programozott logika szerint pl. egyéb felhasználói adatokból, azokat is szépen összekeverve, stb. Így már a forráskódodhoz kell hozzáférnie a hackernek ahhoz, hogy a "sózási logikát" megkapja. Ha a forráskódhoz meg hozzáfért - már nincs mit tenni.
20

Persze a forráskódot jó

Joó Ádám · 2013. Aug. 12. (H), 16.09
Persze a forráskódot jó esetben nem tárolod a szerveren.
21

Mondjuk ezt PHP esetén kicsit

H.Z. · 2013. Aug. 12. (H), 18.02
Mondjuk ezt PHP esetén kicsit nehéz megoldani. ;)
22

A következtetés innentől

Joó Ádám · 2013. Aug. 12. (H), 18.42
A következtetés innentől egyértelmű ;)
23

És az adatbázisod?

Pepita · 2013. Aug. 13. (K), 06.03
Nem a szerveren van? (Másikon, OK, de a következtetés hasonló... :))
25

Hogy jön ez most ide? A

Joó Ádám · 2013. Aug. 13. (K), 12.22
Hogy jön ez most ide? A jelszavak visszafejthetőségéről volt szó. De egyébként az adatbázist is lehet titkosítva tárolni a lemezen.
26

Vegyük észre ...

vbence · 2013. Aug. 13. (K), 16.19
hogy így két szerverhez kell hozzáférést szereznie a támadónak (adatbázis- és alkalmazásszerver). - Ez növeli a szükséges ráfordítást és csökkenti a sikeres támadás bekövetkeztének esélyét is.
27

PHP -> forráskód hozzáférhető

H.Z. · 2013. Aug. 13. (K), 20.40
PHP -> forráskód hozzáférhető -> adatbázis authentikációhoz használt adatokat nehezen lehet elrejteni -> ha megvan a PHP szerverhez a hozzáférés, akkor 99%, hogy az adatbázis is megvan.
28

Zend Guard

Hidvégi Gábor · 2013. Aug. 13. (K), 21.51
47

Ezek használatának van valami

inf3rno · 2013. Aug. 16. (P), 21.26
Ezek használatának van valami hátránya?
48

Fizetni kell értük. A Zendet

Hidvégi Gábor · 2013. Aug. 17. (Szo), 13.09
Fizetni kell értük. A Zendet próbáltam anno, működött, de csak nagyon rövid ideig, így nincs igazán vele tapasztalatom.
49

Fizetni kell értük Ez azért

Poetro · 2013. Aug. 17. (Szo), 18.51
Fizetni kell értük

Ez azért elég természetes. A szoftverek elég nagy részéért fizetni kell, de azért remélhetőleg többet keresel a szoftver használatával, mint amennyibe kerül.
50

Yepp, ha már szóbakerült

inf3rno · 2013. Aug. 17. (Szo), 22.04
Yepp, ha már szóbakerült megnéztem: a zend guard 600$/év, az ioncube 200÷380$/év/gép. Komolyabb rendszereknél évi 200k szerintem nem nagy összeg, mondjuk jobb akkor már eleve olyan nyelven írni, amit befordítasz, aztán akkor az induló költség nagyobb valamivel (drágább egy java programozó, mint egy php), viszont az éves költsége meg kisebb.
51

Csak ezért választani a Javat

BlaZe · 2013. Aug. 19. (H), 09.14
Csak ezért választani a Javat nem sok értelme van, az is elég jól visszafejthető. Úgy általában is vannak kétségeim, hogy mennyi értelme van az ilyen célú törekvéseknek. Ha attól félünk hogy a valaki majd belelát a kódunkba... Ha gépen belül van és látja, akkor már rég rossz, de nem azért mert elolvassa az ifünket :) Hogy esetleg a megbízó átadhatja másnak a projectet? Át. De hiába van ott a forrása, egy összetettebb rendszernél a forrásnál kicsit több kell, hogy át lehessen venni. Fejlesztési környezet, tesztek, az alkalmazás ismerete. Ezek megléte nélkül csak extrém esetben van értelme fejlesztőt váltani, gyakorlatilag irreálisan sokat kér, vagy vállalhatatlanul supportol, fejleszt. Nem mondom, hogy sosem láttam ilyet, de ez ellen meg úgyse véd semmilyen encoder...
52

Az encoder első körben

Max Logan · 2013. Aug. 19. (H), 11.37
Az encoder első körben felmerülhet olyan kontextusban, ahogyan írod, azaz ne vigyék el máshoz a melót. De aki nagyon akarja, úgyis dobni fogja egy az egyben a régi rendszert és irat egy újat. Ami inkább édekes lehet pl. PHP esetén, hogy így biztosítható, hogy nem nyúl bele fű alatt senki, aki úgy gondolja, hogy ért hozzá, azaz minőségbiztosítási (üzemeltetés, support) szempontok miatt érdekes lehet.
53

Egyszerűbb beleírni a

inf3rno · 2013. Aug. 20. (K), 00.22
Egyszerűbb beleírni a szerződésbe, hogy az ilyen módosításokból eredő hibákért nem vállalsz felelősséget. Egy verziókezelővel elég könnyen kiszúrható, hogy volt e hozzányúlás a kódhoz...
54

Van, aki nem használ

Max Logan · 2013. Aug. 20. (K), 00.55
Van, aki nem használ verziókezelőt...

Másik oldalról pedig ha jól tudom, akkor ezek egyben opcode cache-ek is (de lehet, hogy rosszul tudom).
55

Hát verziókezelő nélkül

inf3rno · 2013. Aug. 20. (K), 02.03
Hát verziókezelő nélkül fejleszteni (főleg csapatban) nem tartozik azok közé a dolgok közé, amiket ajánlani tudok. Nem tudok róla, hogy tartozna hozzájuk bármi olyasmi, ami a kód befordításával kapcsolatos. Nyilván ha bináris dolgokat akarsz verziókezelni, azt is meg tudják csinálni, de php-nél én csak kód verziókezelésére használom. A gitet tudom ajánlani, kb 1 nap elolvasni a manualt és képet kapni róla, hogy mi is ez, és mik a lehetőségeid vele.
56

Ami egyébként még érdekes

Max Logan · 2013. Aug. 20. (K), 10.00
Ami egyébként még érdekes ezeknél a megoldásoknál, hogy a forráskód védelmen kívül lehetőséget adnak licenszelésre is. Azaz csak adott IP-n működik a kód, xy dátum után nem működik, stb.

Ami pedig a verziókezelő használatát illeti, van aki jegyzettömbbel kódol, van ki IDE-t használ. Izlések és pofonok...
57

Ami pedig a verziókezelő

inf3rno · 2013. Aug. 20. (K), 10.09
Ami pedig a verziókezelő használatát illeti, van aki jegyzettömbbel kódol, van ki IDE-t használ. Izlések és pofonok...


Nyilván ez a végeredményen is meglátszik...
58

Ez miből következik?

Hidvégi Gábor · 2013. Aug. 20. (K), 10.48
Ez miből következik?
59

Abból, hogy sokszor annyi idő

inf3rno · 2013. Aug. 20. (K), 16.56
Abból, hogy sokszor annyi idő notepaddel ugyanazt produkálni, mint egy IDE-vel automatikus kód formázással, kiegészítéssel, verziókezeléssel stb... Kiskanállal is lehet falat rakni, nem kell hozzá vakolókanál, csak valamivel nehezebb...
61

Vannak a notepad-nél többet

Hidvégi Gábor · 2013. Aug. 20. (K), 17.50
Vannak a notepad-nél többet tudó szövegszerkesztők, valamint egyszerűbb projektek/egyedül dolgozó fejlesztők, akiknek nincs feltétlenül szükségük egy robusztus IDE-re.
63

A hozzászólásban notepadről

inf3rno · 2013. Aug. 20. (K), 21.58
A hozzászólásban notepadről volt szó.
65

A notepad++ pont ugyanolyan

Hidvégi Gábor · 2013. Aug. 21. (Sze), 06.41
A notepad++ pont ugyanolyan ingyenes.
67

IDE

Poetro · 2013. Aug. 21. (Sze), 08.02
Hát a Notepad++ az már igazán közel áll egy IDE-hez, és a Notepad-del ellentétben tényleg ingyenes.
69

IDE

Poetro · 2013. Aug. 21. (Sze), 10.33
Elnézést, PHP szemszögből a Notepad++ teljes értékű IDE, ugyanis plugin segítségével debugger-t is varázsolhatunk bele, és ezzel teljessé válik az IDE élmény.
An integrated development environment (IDE) or interactive development environment is a software application that provides comprehensive facilities to computer programmers for software development. An IDE normally consists of a source code editor, build automation tools and a debugger. Several modern IDEs integrate with Intelli-sense coding features.

Wikipedia - Integrated development environment
72

Én elég sokáig fejlesztettem

tgr · 2013. Aug. 21. (Sze), 11.16
Én elég sokáig fejlesztettem Notepad++-ban, van pár elég komoly hiányossága egy modern IDE-hez képest (főleg kód kiegészítés és navigáció terén), viszont sokkal gyorsabb. Lassabb hardveren, nem túl nagy kódbázisnál kifejezetten ütőképes alternatíva.

Azt viszont nem tudom elképzelni, hogy komoly fejlesztő Notepad-ot használna.
73

Azt viszont nem tudom

Poetro · 2013. Aug. 21. (Sze), 11.22
Azt viszont nem tudom elképzelni, hogy komoly fejlesztő Notepad-ot használna.

Definiáld a komoly fejlesztőt, és hogy Notepad alatt a Notepad melyik inkarnációját érted.
70

Azert a hasonlatod szerintem

Greg · 2013. Aug. 21. (Sze), 11.00
Azert a hasonlatod szerintem nem igazan helytallo. Az hogy en IDE vagy notepad segitsegevel kodolok, csakis engem erint. Viszont a verziokezelo hasznalataval a fejlesztotarsaknak is segitek, mert nyomon tudjak kovetni a valtozasokat.
60

Szvsz aki hajlandó fizetni

tgr · 2013. Aug. 20. (K), 17.49
Szvsz aki hajlandó fizetni azért, hogy az obfuscatorral fordított változatát kapja meg a kódnak, és a forráskódját nem, annak önveszélyes mértékben hiányzik az üzleti érzéke, és ilyen embernek dolgozni sem tartozik az ajánlatos dolgok közé (pl. mert mire elkészülsz, csődbe megy, és nem fog tudni kifizetni).
62

Miért baj az, ha valaki zárt

Hidvégi Gábor · 2013. Aug. 20. (K), 18.49
Miért baj az, ha valaki zárt forráskóddal adja el a szoftverét (azaz gyakorlatilag csak a használati jogot)? Így például árban a vetélytársak alá mehet. Az ügyfél fizetési hajlandóságát könnyen lehet tesztelni azzal, hogy előleget kér az ember; ha ezt nem hajlandó elfogadni, akkor valóban lehetnek gondok. Szóval léteznek más üzleti modellek is.
64

Végülis ez is egy üzleti

inf3rno · 2013. Aug. 20. (K), 22.03
Végülis ez is egy üzleti modell lehet, hogy tized áron használati jogot adsz, minthogy örökös használati jogot adsz normál áron az ügyfélnek. (A szoftverre vonatkozó szerzői jogodról ha jól tudom nem lehet lemondani.) Viszont ő így jobban ki van szolgáltatva neked, ami egy kellemetlen diszkomfort érzés, hogy az intim betét reklámokból idézzek...
66

Ha nem tud többet fizetni,

Hidvégi Gábor · 2013. Aug. 21. (Sze), 06.44
Ha nem tud többet fizetni, akkor be kell érnie ennyivel.
68

Körül kell nézni a szoftver

Max Logan · 2013. Aug. 21. (Sze), 10.19
Körül kell nézni a szoftver piacon, elég változatos az értékesítési modellek palettája. A felhő alapú megoldások esetén pedig ugye eleve csak használati jogot vásárol az ember, mondjuk havi vagy éves fizetési konstrukcióban. Minden konstrukciónak van előnye és hátránya mindkét fél szemszögéből.
71

Kiszolgáltatva lenni mondjuk

tgr · 2013. Aug. 21. (Sze), 11.12
Kiszolgáltatva lenni mondjuk a Microsoftnak, az egy dolog. Kiszolgáltatva lenni Gipsz Jószikának, akinek talán nem ez az első projektje életében, és méginkább talán azt is megoldotta, hogy nélküle is ki tudd nyerni az alkalmazásából az ügyféladatbázist meg az invertory-t, ha őt elüti egy kamion, de az összes belefektetett üzleti intelligencia már biztosan odaveszik, és kezdheted nulláról egy másik fejlesztővel - ebbe normális üzletember nem megy bele.

Emellett a webalkalmazásoknál jellemzően nem reális, hogy tizedannyiért eladod a használati jogot, mert a karbantartás és az új felhasználói igények folyamatos beépítése teszi ki a nagy részét a munkának. Nem nagyon fordul elő, hogy egy cég megvesz egy alkalmazást, ami a core business modeljének a része (mondjuk egy webshopot), és az aztán elüzemel évekig anélkül, hogy módosítani kéne.
74

Ismerősi körömben, ami most

Hidvégi Gábor · 2013. Aug. 21. (Sze), 12.16
Ismerősi körömben, ami most már teljesen szabadúszókból áll, mindenki zárt forrású szolgáltatást nyújt az ügyfeleinek az utóbbi nagyjából nyolc-tíz évben. Az, hogy mennyire megbízható valaki, megítélni valóban kockázatos, de az általa felmutatott referenciák számából és minőségéből elég jól lehet becsülni.

Ezek miatt a szolgáltatások karbantartása és fejlesztése nem szokott gond lenni náluk. Az adatok exportálását pedig bárki kérheti, amit akár kézzel, akár pedig programozottan is el lehet végezni.

Továbbá azt, hogy mi a jó üzlet – és ezt minden tisztelettel mondom –, kétlem, hogy a weblabor fórumára írók nagy többsége meg tudná ítélni. Azt meg tudjuk mondani, hogy az md5-öt vissza lehet-e fejteni vagy sem, mert ebben van gyakorlatunk, ezzel foglalkozunk legalább napi nyolc órában, de üzleti tapasztalata nem hiszem, hogy sokaknak van.
75

Az üzlet az egy olyan valami,

Max Logan · 2013. Aug. 21. (Sze), 12.54
Az üzlet az egy olyan valami, amihez mindenki saját értékrendet és nézőpontot párosít. Így ami másnak rossz üzlet, nekem lehet, hogy jó, mert eléggé különbözik az értékrendünk.

Nincsen olyan, hogy jó vagy rossz üzlet. Élethelyzetek, nézőpontok és értékrendek vannak, melyek mentén kezdvezőbb vagy kevésbé kedvezőbb lehetőségekről beszélhetünk. Hogy a külső szemlélő mit lát, mit ítél meg a saját nézőpontja és értékrendje alapján, teljességgel lényegtelen.
76

De van, szerintem

Pepita · 2013. Aug. 21. (Sze), 14.25
Nincsen olyan, hogy jó vagy rossz üzlet.
Egy üzleti kapcsolathoz legalább két üzletfél kell, akik valamilyen üzletet kötnek.
Véleményük - ahogy te is írod - részben szubjektív az adott üzletről.
Ha azonban mindegyik fél elégedett az üzlettel, akkor azt igenis jó üzletnek nevezhetjük. (És vice versa.)
Ebből a szempontból lényegtelen a "külső szemlélők" álláspontja, főként azért, mert javarészt nem látnak bele teljesen az üzletbe (lévén üzleti titok).
Tehát szerintem nagyonis létezik egyetemleges értelemben is jó és rossz üzlet. (Természetesen minden egyénnek a saját szemszögéből nézett jó és rossz a legmérvadóbb, azt nem vitatom.)
46

Más szint

vbence · 2013. Aug. 16. (P), 19.35
ha megvan a PHP szerverhez a hozzáférés

Azért más szint, hogy fájlok tartalmához hozzáférünk a szerveren, vagy hogy kódot tudunk futtatni rajta.
24

Na jó, akkor szakértek...

H.Z. · 2013. Aug. 13. (K), 08.14
Na jó, akkor szakértek... :D
Nézd meg a crypt függvény működését, különös tekintettel az általa visszaadott értékre! ;)
Konkrétan arra céloznék, hogy a visszaadott, tárolandó értékben benne van a só értéke.
Mivel a sózás a szivárványtáblák elleni védelmen túl semmi plusz védelmet nem ad, nincs értelme rejtegetni. Az is elég, ha minden tárolt jelszóhoz másik sót használsz, nyugodtan tárolhatod a jelszóval együtt.

Amiről te beszélsz, az már nem a sózás, hanem a két jelszavas beléptetés, amit eddig viszonylag kevés rendszeren láttam. Használni meg talán egyetlen helyen, ott is feleslegesen. :)
32

Peppernek hívják, és nem kell

tgr · 2013. Aug. 15. (Cs), 17.53
Peppernek hívják, és nem kell hozzá két jelszó; a hash algoritmusnak van egy jelszavanként különböző és egy globális kulcsa, és az utóbbit valami eltérő helyen (a forráskódban, vagy egy konfigurációs fájlban) tárolod. Valamivel nehezítheti a támadó dolgát, például egy SQL injectionnel nem lehet megszerezni (a sóval ellentétben). A gyakorlatban óriási haszna nincsen, mert az SQL injection ellen amúgy is viszonylag könnyű védekezni.
38

A peppernek van haszna

inf3rno · 2013. Aug. 16. (P), 01.04
A peppernek van haszna szerintem, ha sikerül lenyúlni az adatbázist, és ismerik az algoritmust, akkor tudnak egyedi szivárványtáblát csinálni csak az admin salt-jára. Itt jön be a képbe a pepper, ha a jelszót nem magában, hanem a pepper-el megtűzve küldöd el, akkor hiába csinálnak neki egyedi szivárványtáblát, mert a pepper-el megtűzött jelszó túl hosszú lesz nekik.

Elég hash(pepper+password, salt)-ot használni. Az algoritmus szinte mindegy is, hogy mi szerintem, amíg a peppert nem szerzik meg, addig kevesek a dekódoláshoz. Vajon ismert jelszó és salt alapján meg lehet mondani a peppert?
40

Szivárványtáblát semmi

tgr · 2013. Aug. 16. (P), 04.19
Szivárványtáblát semmi értelme csinálni, ha csak az adminjelszót akarod feltörni, sőt általában nincs értelme sózott jelszavaknál. A szivárványtáblának az a lényege, hogy kiszámolod az összes téged érdeklő string hash-ét, és az eredényt letárolod egy olyan adatszerkezetben, amiben az adatok valamilyen értelemben tömörítve vannak (a kinyerésük számításigényes, de sokkal kevesebb helyet foglalnak, mint naivan letárolva): egy adott hash visszafejtéséhez n hash műveletet kell végezni, ugyanakkor csak minden n-edik hasht kell letárolnod. Ez akkor jó, ha el tudod végezni előre a számításokat, még mielőtt ellopnád az adatbázist, és így időt takarítasz meg. Sózott adatbázisnál 1) nem tudod előre kiszámolni a hasheket, 2) amúgy is minden jelszóra külön kell, úgyhogy a szivárványtáblának semmi értelme.

Szivárványtáblát ma egyébként se lenne értelme használni. A jelszótörésnél végső soron az a korlát, mennyi pénzed van rá. Ha elég pénzed van, vehetsz több számítási kapacitást, vagy több tárhelyet, amin letárolod a kevesebb számítási kapacitással hosszabb idő alatt kinyert hashtáblát; a közelmúltban a számítási kapacitás ára sokkal gyorsabban csökkent, mint a tárhelyé, úgyhogy kifizetődőbb azt venni, és on the fly számolni a hasheket.

A pepper egyszerűen arra való, hogy eggyel több helyet kelljen feltörni ahhoz, hogy a jelszóhashelő algoritmust reprodukálni tudja a támadó. Ha az adatbázishoz hozzáfér, de a fájlokhoz nem, akkor a pepper megvéd. A gyakorlatban azért van kevés haszna, mert az ilyen szituáció ritka: SQL injection ellen könnyű védekezni, úgyhogy ha valaki elvitte az adatbázisodat, azt valószínűleg úgy csinálta, hogy be tudott jelentkezni a szerveredre, és akkor elvitte a forráskódot is.
42

és akkor elvitte a

Joó Ádám · 2013. Aug. 16. (P), 04.42
és akkor elvitte a forráskódot is


Ezért kell fordított nyelvet használni :)
30

Ha beszórsz egy 32 karakteres

inf3rno · 2013. Aug. 15. (Cs), 17.26
Ha beszórsz egy 32 karakteres sót a jelszavad mellé, akkor nem lehet szivárványtáblával visszafejteni, mert nem nagyon vannak 10 karakternél hosszabb szavakat tartalmazó táblák. Ezek már petabyte-os méretek...

Ilyenkor külön minden salt-ra csinálni kell szivárványtáblát, és egyesével megnézni a jelszót. Ha nem tudják az algoritmust, akkor így esélytelen, ezért szoktak pl ciklusokat csinálni md5(salt.md5(salt.password)), stb...

A brute force ellen az véd, ha erőforrás és/vagy időigényes a hash készítése, pl blowfish algoritmusnál ez van. Ezeket direkt ilyen célra találták ki, az md5 és sha1 nem ilyen, azok nagyon gyorsak... Egyszerűbb védekezés brute force ellen, ha 50 db egymás utáni sikertelen próbálkozás után töröljük a jelszót és erről emailt küldünk, vagy ideiglenesen zároljuk a fiókot jelszavas belépésre. A cookiek, linkek sokkal hosszabb karakter láncokat tartalmaznak, mint a jelszavak, azok ellen nincs esélye a brute force-nak.
34

A brute force tipikusan abban

tgr · 2013. Aug. 15. (Cs), 18.36
A brute force tipikusan abban a szituációban jön elő, hogy ellopják az adatbázisodat, és offline megpróbálják feltörni; ez ellen a hibás bejelentkezés limitálás nem véd. Online feltörésnél sokkal lassabb jelszavakat próbálgatni (offline támadásnál 10^10 körüli jelszót ki lehet próbálni másodpercenként, egy webszerver mondjuk 10^2 requestet tud megválaszolni ennyi idő alatt), úgyhogy az maximum arra jó, hogy tipikus gyenge jelszavakat végigpróbálgassanak (ez ellen kell a throttling).
35

A brute force tipikusan abban

Max Logan · 2013. Aug. 15. (Cs), 21.30
A brute force tipikusan abban a szituációban jön elő, hogy ellopják az adatbázisodat [...]
Most már komolyan érdekelne, hogy a valóságban ez hogyan is történik meg, azaz miként lopnak el egy adatbázist?
36

Adatbázis nem csak sok

H.Z. · 2013. Aug. 15. (Cs), 21.39
Adatbázis nem csak sok terabyte-os valami lehet. ;)
(bizonyos szempontból a /etc/passwd-/etc/shadow duó is adatbázis.
És épp elég, ha hozzáférnek az adatbázisban tárolt usernevekhez és kódolt(már ahol :( ) jelszavakhoz, ha nem elég jó a kód/hash.
41

Gondolom egyszerűen

tgr · 2013. Aug. 16. (P), 04.23
Gondolom egyszerűen bejelentkeznek a szerverre (valamilyen oprendszer sebezhetőséget vagy az alkalmazás remote code inclusion vagy hasonló sebezhetőségét kihasználva) és letöltik. Vagy feltörik valamelyik fejlesztő gépét, aki az éles adatbázist használja tesztelésre. Vagy feltörik a backup szervert. Stb.
9

Az md5 nem titkosító, hanem

LaySoft · 2013. Aug. 9. (P), 20.49
Az MD5 nem titkosító, hanem hash algoritmus, ezért a "visszafejthető" kérdés eleve értelmetlen, mivel végtelen bemenete lehet, de véges, 2 a 128-adikon kimenetet ad.

Egy hash algoritmus két feltételnek kell hogy megfeleljen:

1. Nem "hamisítható", vagyis tetszőleges hash értékhez nem lehet (ill. igen nehéz) olyan adatot előállítani, ami az adott hash-t eredményezné. Ennek az MD5 máig ellenáll.

2. Két különböző bemenő adat mindig különböző hash-t ad. Ez az, aminek már nem áll ellen, mert találtak ún. ütközést, és van is program, ami pár perc alatt generál ilyet.

A nagy baj akkor lenne, ha az első feltételnek nem felelne meg, mert akkor sok protokoll használhatatlanná válna. A második feltétel megdőlését a gyakorlatban támadásra nem lehet kihasználni, mindenesetre azért jelzi, hogy az algoritmus sebezhető, ezért érdemes váltani olyanra, ami ellenáll mindkét feltételnek, pl. SHA-ra.
12

Ütközés alapú támadások

complex857 · 2013. Aug. 10. (Szo), 14.50
Hash ütközéseket is lehet többféle támadásra használni:
  1. Digitális aláírások: Egy ütköző hash -et kihasználva elérhető lehet, hogy egy certificate authority kiadjon egy tanúsítványt X domainre, de egy másik, ugyanazt a hasht generáló domain névre is érvényes legyen. Konkrétan md5 -el kapcsolatban publikáltak is pár erre a problémára épülő támadást pár éve, Wikipedián van pár linkelve ilyen.
  2. DOS: Ha a támadott fél oldalán van valamilyen hashmap jellegű adatszerkezet amibe támadó egy sor ütköző adatot tud tölteni (pl.: HTTP paraméterek) akkor a támadott oldalon futó program teljesítménye drasztikus romlásba kezd (O(1)-ből O(n^2) lesz legrosszabb esetben). Konkrétan persze senki se használ md5 -t hashmapjeihez, de a probléma előkerült számos programozási nyelv / környezet kapcsán. Konkrétumokért érdemes meghallgatni ezt az előadást (diák).
17

A Flickr-t például pár éve

tgr · 2013. Aug. 10. (Szo), 20.58
A Flickr-t például pár éve egy hash ütközés jellegű támadással törték meg.
29

Igazad van, úgy látszik

LaySoft · 2013. Aug. 14. (Sze), 13.36
Igazad van, úgy látszik régóta nem követtem figyelemmel a hash collision kihasználásokat, nem tudtam hogy létezik már chosen prefix attack is. Azért ez a certificate ütközés elég durva, úgyhogy MD5 felejtős, tényleg.
14

Az egy népszerű legenda, hogy

tgr · 2013. Aug. 10. (Szo), 20.06
Az egy népszerű legenda, hogy ha jelszavakat akarsz tárolni, akkor md5 helyett sha1-et (modernebb változatokban sha512-t) kell használni, mert az md5-öt "megtörték". A valóságban mindegyik pont ugyanolyan rossz jelszavak tárolására, és ennek nem az ütközésekkel szembeni sebezhetőséghez van köze, hanem ahhoz, hogy nagyon gyorsan számítható (külön hátrány, hogy célhardveren sokkal hatékonyabban számítható, mint egy tipikus szerveren).
13

A rövid válasz az, hogy nem

tgr · 2013. Aug. 10. (Szo), 20.01
A rövid válasz az, hogy nem visszafejthető. A hasznos válasz az, hogy ha md5-öt használsz, akkor az esetek 99,9%-ában nem a visszafejthetőség érdekel, hanem az alábbiak valamelyike:
- lehet-e találni két olyan szöveget, aminek ugyanaz az md5 hashe? (Lehet; ezt szokták leegyszerűsítve úgy megfogalmazni, hogy az md5-öt megtörték. "md5 collision attack" kulcsszóra guglizva tetszőleges mennyiségű információt lehet találni róla.) Ez tipikusan a digitális aláírásoknál érdekes.
- ha nagy vonalakban tudod, hogy néz ki az eredeti szöveg (pl. csak számokból és betűkből áll, és kevesebb, mint 10 karakter), akkor ki tudod-e találni, mi volt az? A válasz az, hogy csak úgy, ha végigpróbálgatod az összes lehetőséget, hogy ugyanazt a hasht adja-e; de az md5 nagyon gyorsan számolható, ezért gyakran ez elég is. (Pl. az összes <8 betűs szót percek alatt végig lehet próbálgatni.) Ez tipikusan a jelszavak tárolásakor érdekes.
31

És ha ciklusban

inf3rno · 2013. Aug. 15. (Cs), 17.39
És ha ciklusban használod?

$salt = sha1(base64_encode(mcrypt_create_iv(mcrypt_get_iv_size(MCRYPT_CAST_256, MCRYPT_MODE_CFB), MCRYPT_DEV_URANDOM)));
$hash = $password;
foreach (range(1, 1000) as $i)
    $hash = md5($salt.$hash);
Bár gyorsan megvan, azért volt tüske nálam a processzoron, ha sokat nyomkodtam...
33

Ha jól állítod be a

tgr · 2013. Aug. 15. (Cs), 18.26
Ha jól állítod be a ciklusszámot, ez egy vállalható megoldás, de akkor már használhatod a PBKDF2-t, ami hasonló elven működik, de sokkal menőbben hangzik :)

A bcrypt annyival jobb, hogy olyan műveleteket használ, amiket nem lehet egy az egyben regiszter-műveletekre lefordítani, ezért csökkenti valamivel a GPU-nak a CPU-val szembeni relatív előnyét.
37

Okés.

inf3rno · 2013. Aug. 15. (Cs), 21.41
Okés, ha jól olvasom a cikluszámra eredetileg ezret ajánlottak, ma meg már inkább 2000-et, mert nőtt a gépek teljesítménye. Azt hiszem, akkor betolok kezdésnek egy 2000-es ciklus számot, kíváncsi vagyok hogy bírja a szerver.
39

Még az is elég kevésnek

tgr · 2013. Aug. 16. (P), 03.49
Még az is elég kevésnek hangzik. A sha256crypt eredeti implementációjában 5000 kör volt a default, és annak már öt éve (és a sha256 kb. háromszor lassabb, mint az md5). De persze szervere válogatja; érdemes kimérni, mi az a legnagyobb iterációs szám, ami még nem okoz érzékelhető lassulást (mondjuk néhány 10 ms).

És itt jön képbe a különböző algoritmusok különböző hatékonysága GPU-n: a GPU-s törés ellen kifejlesztett algoritmusok (bcrypt, scrypt, sha*crypt) esetében ami neked 10ms, az nagyságrendileg a támadónak is annyi, sima md5 iteráció esetén van vagy 4 nagyságrend előnye, mert egy GPU annyival gyorsabb, mint egy CPU.
43

Hát akkor az md5 nem sokat

inf3rno · 2013. Aug. 16. (P), 13.55
Hát akkor az md5 nem sokat ér...

Saját gépen az md5 13333 ciklussal 30 msec körül van, ahogy nézem a szerveren is hasonló...
44

Alapvetően kétféle hash

tgr · 2013. Aug. 16. (P), 15.15
Alapvetően kétféle hash algoritmus van sebesség szempontjából: amit arra terveztek, hogy gyors legyen, meg amit arra terveztek, hogy ne legyen gyors. Ha például az új Ubuntu disztró letorrentezését szeretnéd biztonságosabbá tenni azzal, hogy kiszámolod és egy más csatornán közzéteszed az md5 hash-ét, akkor nem lenne jó, ha minden 32 bájtonként miliszekundumokig tartana a kiszámítása. Szóval mondjuk úgy, hogy az md5 jelszavak védelmére nem sokat ér.

Persze lehet md5-ből iterálással erősebb eljárást csinálni (ezt teszi a PBKDF2 is), de általában nem jó ötlet saját algoritmusokat kitalálni, ha van standard; erős építőkockákból is össze lehet rakni gyenge végeredményt, ha nem tudod, hogyan kell helyesen alkalmazni őket.

Standard jelszóvédő algoritmusból pedig nagyjából három van: PBKDF2, bcrypt, scrypt. (Elvileg a sha256crypt, sha512crypt is ilyen, de azok kevésbé népszerűek, és nem sokat tudok róluk.) Ebben a sorrendben egyre erősebbek (a PBKDF2 csak egy gyors hash iterálása pár finomsággal, a bcrypt iterációnként más-más műveletet végez, ezért sokkal kevésbé lehet GPU-n felgyorsítani, az scrypt tetszőlegesen sok memóriát igényel, ezért GPU-val vagy FPGA-val sem lehet sokkal olcsóbban számolni, mint CPU-val) és egyre kevésbé "állták már ki az idő próbáját" (a PBKDF2 elég régi és NIST certified, az scrypttel még inkább csak kriptográfusok játszottak eddig, nagy rendszerekben nem sokat használták); valamennyire ízlés dolga, melyik szempontot részesíti valaki előnyben, legtöbbször arany középútként a bcryptet szokták ajánlani.
45

Ja, én is a bcryptet látom

inf3rno · 2013. Aug. 16. (P), 19.10
Ja, én is a bcryptet látom mindenhol, scrypt-et nem is nagyon ismerik.
19

+1 tgr

Pepita · 2013. Aug. 11. (V), 00.24
Én azt javaslom, itt hallgassunk csak tgr-re, én többször tapasztaltam nála, hogy hash-matek téren igen otthon van. Annyit kérek cserébe, hogy az én honlapjaimat ne törd fel légyszi! :)
77

Admin jelszó visszafejtése SQL

Mikulasche · 2013. Okt. 12. (Szo), 10.16
Van egy működő webárúház.
A programozó meghalt.
Nekem mindenhez teljes a hozzáférésem.
Szerver - Adatbázisszerver - sql - minden.

De a programozó admin jelszava titkosítva van az sql adatbázisban.

Bizonyos dolgokhoz meg csak azzal lehet hozzányúlni.

Ki lehet e nyerni valahogy a jelszót ?
78

Uj tema

janoszen · 2013. Okt. 12. (Szo), 10.21
A Weblaboron az a szokas, hogy uj kerdes uj temaba megy, igy nincsenek kilometeres temak. Kerlek, kuldd be a kerdesedet uj forumtemakent es kicsit reszletesebben ird le, hogy mirol van szo.

Ha egyedi fejlesztesu a szoftvered es nem ertesz hozza, akkor viszont jobb, ha az Allas rovatba kuldod be, mivel valoszinuleg ugyis valakinek meg kell csinalnia helyetted.
79

Módosítsd

Poetro · 2013. Okt. 12. (Szo), 10.23
Hát akkor módosítsd az adatbázisban egy általad ismert jelszóra az ő jelszavát.
80

védelem

Gixx · 2013. Okt. 15. (K), 15.34
Ha jelszót akarsz kódolni, és validálni, akkor olyan megoldást keress, ami ritka, vagy szokatlan, és emiatt nem fognak rá gondolni, akik megszerzik a kódolt jelszót. De semmiképp ne használj fix hosszúságú encrypt megoldást, mert az már félig behatárolja, hogy merre kell keresgélni.

Szerintem a többség md5-öt használ, vagy sha1-et. A Bcrypt már jobb, igaz PHP libraryként elég lassú, de azt hiszem az új PHP-ban már natívan is benne lesz.

De ha ráérős vagy, kísérletezhetsz egészen eszement megoldásokkal, pl.:
- a jelszót kiírod egy fájlba és abból csinálsz egy hash-t.
- fogsz egy 1 bájtos fájlt, azt bezipeled, a zipet jelszavazod, majd az így kapott fájlra tolsz egy fájl hasht.

Lassú, fölösleges, de viccnek és gyakorlásnak jó.

És fájl hashaléshez szintén ne MD5 legyen, hanem mondjuk Haval:
hash_file('haval160,4', $file);
81

A Bcrypt by design lassú, az

MadBence · 2013. Okt. 15. (K), 15.52
A Bcrypt by design lassú, az a hash, amit lassan lehet számolni, ellenállóbb a brute-force módszerekkel szemben.
82

Login

Gixx · 2013. Okt. 15. (K), 17.01
Igen, de nem mutat jól, hogy 5-6 másodperc egy login :) Mondjuk nekem ez virtuális gépen ennyi...
83

Nyilván lehet állítani, hogy

inf3rno · 2013. Okt. 16. (Sze), 00.02
Nyilván lehet állítani, hogy mennyi egy login, tgr szerint ha megszerzik az adatbázisodat, akkor a kódodat is megszerzik hozzá, onnan meg ha elég gyors a hash készítés, akkor pillanatok alatt feltörik az összes jelszót...
84

ha kód is van...

Gixx · 2013. Okt. 16. (Sze), 17.20
Ha a kódot is megszerzik, meg a DB-t is, akkor nem is kell törni. Kódolsz egy tetszőleges jelszót a kód alapján, majd ezzel tolsz egy password update-et az összes userre.
85

Ennek mi értelme? :)

Joó Ádám · 2013. Okt. 17. (Cs), 15.14
Ennek mi értelme? :)