ugrás a tartalomhoz

Bejelentkezés titkosítása

halee · 2005. Ápr. 18. (H), 18.04
Sziasztok!

Az lenne a kérdésem, hogy megoldható-e, az PHP-ből, hogy a form-ról küldött adatok ne nyíltan menjenek át a neten. Gondoltam Js-es megoldásra, de nem túl jó mivel, ha adott gépen tiltott a Js nem tudok bejelentkezni...
A lényeg az lenne, hogy saját titkosító algoritmust szeretnék használni, valamint, hogy mindenképpen kliens oldalon titkosítsam a user+pass-t. (lehetőleg HTTPS/SHTML nélkül vagy ha azzal akkor részletesebb leírás is kéne... :) )

Köszi, Halee
 
1

Jah és ami kimaradt:

halee · 2005. Ápr. 18. (H), 18.06
Jah és ami kimaradt: Lehetőleg a tanusítványos ablak nélkül!!! Tehát a usernek nem kellene teletömni a fejét olyan infóval, amiről azt sem tudja, hogy mit jelent... :)

Megint köszi, Halee
2

https

kmm · 2005. Ápr. 18. (H), 18.11
--
üdv: kmm...
3

azaz mégsem

kmm · 2005. Ápr. 18. (H), 18.27
nyilvanvaloan latszik, hogy nem olvastam el a hozzaszolast amire valaszoltam :(
elnezest kerek.

--
üdv: kmm...
4

Számomra nem egészen

fchris82 · 2005. Ápr. 18. (H), 19.05
Számomra nem egészen világos, miért akarsz saját titkosító módszert használni, ha már egyszer ott a https. Ha már annyira fontos ez a biztonság, hogy titkosítasz, akkor a felhasználónak nyílván van annyi esze, hogy nem jön zavarba egy hitelesítési ablaktól. Ha meg mégis, akkor a rendszerben a leggyengébb láncszem az alulképzett felhasználó lesz, az a típusú, aki a monitor sarkára írja fel a jelszókat és felhasználó neveket.
A saját titkosító algoritmusok messze nem olyan megbízhatók, mint bármi más, ami a kereskedelemben elterjedt.
Na jó, lehet jobb, de arra elég kicsi a valószínűség ;) Ha be akar vki jutni, be fog jutni. Nehezebb a dolga https-en keresztül, mint kitalálni a te "primitív" algoritmusodat.

Most, hogy ennyit beszéltem arról, miért ne csináld úgy, ahogy kitaláltad ;) , a következőt javaslom arra, ha mégis ragaszkodsz hozzá:
Javaban írj egy bejelentkező appletet, és az küldje el az adatokat a szerverrel kommunikálva. Sztem :)
5

Java Decompiler

Balogh Tibor · 2005. Ápr. 18. (H), 23.58
A java bájtkód könnyen visszafejthető forráskóddá, pl: DJ Java Decompiler-rel. A java applet nem sokkal nyújt nagyobb biztonságot mint a Javascript.
6

Ez való igaz :)

fchris82 · 2005. Ápr. 19. (K), 00.33
Ez való igaz :)

DE! Ha egy titkosító algoritmus "megfejthetetlenségét" arra alapozod, hogy "nem ismert (publikus) az eljárás", akkor az már eleve egy halott kezdeményezés.
A titkosító algoritmusok erősége pont abban rejlik (amit ténylegesen használnak is!), hogy mindenki tudja hogyan működik, mégsem tudják feltörni (vagy csak nehezen, az esetek többségében megkerülve, az embert felhasználva).
Azért javasoltam a Java-t, mert abban megoldható, hogy egy már ismert, a jelenlegi HTTPS-nél biztonságosabb algoritmust/titkosítást/erősebb kulcsot/zavaró elemek nélkül, a böngészőt kihagyva a játszmából lehessen belépni, és ezzel ki van váltva a gyengének/zavarónak vélt HTTPS. Ezt JavaScriptben nem hozod össze :)
7

Ezzel is van baj...

kgyt · 2005. Ápr. 19. (K), 09.25
A java esetén meg az a baj, hogy vakok nem igazán fognak tudni belépni az oldalra, ha mégis, akkor elég nagy szenvedés árán.
A legtöbb vak ugyanis nem képes a java elérésére, a java accessibility pedig igencsak gyermekcipőben jár jelenleg.
+ ha nincs java, nincs belépés? Ez durvább, mint a belépés javascript igénye, javascriptet még a links is tud, a java azon túl, hogy sokaknál nincs is telepítve, karakteres felületen biztosan nem érhető el.

--
Szeretettel: Károly György Tamás
kgyt&kgyt.hu - http://kgyt.hu
8

Java

Balogh Tibor · 2005. Ápr. 19. (K), 11.50
"Azért javasoltam a Java-t, mert abban megoldható, hogy egy már ismert, a jelenlegi HTTPS-nél biztonságosabb algoritmust..."
Csak igen felületesen ismerem a https protokolt, majdhogynem sehogy, de egészen biztos, hogy nem csak abból áll, hogy használ egy titkostó - talán az SSH - algoritmust. A böngésző a kapcsolathoz használ egy tanúsítványt - amit egy harmadik fél igazol - azért, hogy biztosítsák, hogy az adatok nem sérülnek a kommunikáció során. Nem hiszem, hogy a https protokol gyenge lenne, ha azt használják banki tranzakciók során.

"Ha egy titkosító algoritmus "megfejthetetlenségét" arra alapozod, hogy..."
Nem tudom mennyire ismert dolog, de az USA-ban nem lehet csak olyan titkosító algoritmust alkalmazni (vagy szabadalmaztatni) amit a CIA záros hataridőn belül fel tud törni. Legalább is az egyik volt tanárom ezt állította.
9

128 bit

kgyt · 2005. Ápr. 19. (K), 12.01
Asszem 128 bit a maximális SSL is (a 2048-as RSA-ról álmodni sem mernek).
Nem vagyok benne 100%-osan biztos, én is csak hallottam... :-)

--
Szeretettel: Károly György Tamás
kgyt&kgyt.hu - http://kgyt.hu
11

??

Balogh Tibor · 2005. Ápr. 19. (K), 22.27
Mi az fiatalok, az "egyik volt tanárom ezt állította" megjegyzés ennyire gyerekesnek tűnt?

Szeretettel Balogh Tibor :)
10

nekm is ezt állította az

Fekete Ferenc GDA · 2005. Ápr. 19. (K), 19.41
nekem is ezt állította az egyik tanárom:) mármint az fbi/cia-s dolgot. Egyébként biztosan így van.

ferenc voltam
12

Tehát, akkor:

Anonymous · 2005. Ápr. 20. (Sze), 15.00
Tehát, akkor:
1. A HTTPS valóban elég biztonságos, felesleges vessződni a kiváltásával, úgyse lesz jobb.
2. A vakos dolog is igaz, ez is a HTTPS mellett szól.
3. A CIA-s dolog lehet, hogy létezik a gyakorlatban, de könnyen kikerülhető, és egy része hülyeség.
- a 2048 bites RSA kulcsot akkor sem tudod emberi időn belül törni, ha a világegyetem össze atomja egy szgép, és egy számítás annyi ideig tart, amennyi idő alatt a fény átmegy az atommagon! Bárki utána számolhat, a neten fent van minden adat (H atommag ámérő, világegyetemben előforduló összes atom, fénysebesség)
- a USA kormány pár éve változtatott filozófiáján, a cél az volt, hogy amit ők titkosítani akarnak, az biztosan titkos is maradjon. Kiírtak egy pájázatot, amire kb 60 pályázat érkezet. Ezután jött egy évekig tartó "küzdelem" a pályázatok között. Egymás algoritmusaiban keresték a hibákat, törhetőségket, nem csak a pályázó cégek. A végén maradt két algoritmus, amik közül az AES nyert, mert az övé vmivel gyorsabb volt.
- A PGP/GPG két kulcsos titkosítást használ, és mint az első részben írtam, egy 2048 bites kulcsot nem fog senki feltörni. Éppen ezt használta ki egy nagyobb drogkereskedő hálózat feje. Jött az FBI, hozzáfértek vhogy a szgépéhez, megszerezték a privát kulcsot, és a billentyűzet-szgépház közé beiktattak egy kis ketyerét (neten rendelhető!), ami logolta a billentyűzet leütéseket. Így megszerezték a privát kulcshoz tartozó kódot, és vissza tudták fejteni a levelezését. Más módszerrel ez nem ment (volna).
13

Az előzőt én írtam, csak

fchris82 · 2005. Ápr. 20. (Sze), 21.56
Az előzőt én írtam, csak az egytemen nem jelentkeztem be :o) Bocsi :)
14

Köszi a

halee · 2005. Ápr. 21. (Cs), 18.04
Köszi a hozzászólásokat!

Hol találok egy rendes leírást a https-ről???
15

HTTPS-ről. Talán segít

Anonymous · 2005. Ápr. 26. (K), 11.33
Engem is érdekelt ez a kérdés, és a következő dokumentum leírja, hogy hogyan kell ilyet csinálni. Kulcsot, certification-t generáltatni, stb. Sztem hasznos!

http://www.ibiblio.org/pub/Linux/docs/HOWTO/translations/hu/html_single/Apache-WebDAV-LDAP-HOWTO-hu.html#intro

Remélem ez segít
16

Leírások

Török Gábor · 2005. Ápr. 26. (K), 17.13
Wikipédiában angolul ezt írják róla: http://en.wikipedia.org/wiki/Https
Itt pedig egy klassz leírás szintén angolul, miként lőheted be Apache-csal: http://www.gallowglass.org/#1

--
slink
17

Hali!javaslom használj

Anonymous · 2005. Ápr. 27. (Sze), 00.18
Hali!

javaslom használj a https-t az RSA-nál jobb algoritmust te sem fogsz tudni írni! :) Az apache beállításokat bízd a rendszergazdára! ;)

Üdv: Gábor