ugrás a tartalomhoz

tippet szeretnék beléptető rendszer

Pallosi Péter · 2013. Már. 1. (P), 17.18
sziasztok egy beléptető rendszert készítek tudnátok valami tippet ötletet,hogy milyen funkciókat tartalmazzon?
valami komplexebb dologot akarok csak nem tudom mit tartalmazzon szerintetek?
‹ A $_SESSION PHP tömbök MySQL adatbázisban tárolása Többnyelvű blog megvalósítása ›
 ■
1

Milyen funkciókat

Hidvégi Gábor · 2013. Már. 1. (P), 17.30
Milyen funkciókat tartalmazzon?
  • Lehessen belépni
A második mondatodat ellentmondás feszíti. Legyen komplex, de fogalmad sincs, hogy micsoda?
2

egyéni

Pallosi Péter · 2013. Már. 1. (P), 17.36
olyan tippet szeretnék amitől egyéni lesz a beléptető felület de valami bonyolultabb dogot keresek tehát valami feladatot tudtok unatkozom és gyakorolni akarok.
3

A királynét megölni nem

BlaZe · 2013. Már. 1. (P), 17.42
A királynét megölni nem kell félnetek jó lesz... :)

Elsőre pls használj írásjeleket, mert alig érteni, amit írsz. És szerintem írd le, hogy mi van a fejedben eddig erről, és hogy mire és hogy szeretnéd pontosan használni.
6

Bocsi

Pallosi Péter · 2013. Már. 1. (P), 18.10
Bocsánat csak telefonról voltam és eléggé nehéz arról gyorsan gépelni.
4

Manapság elég egyéni, ha a

Hidvégi Gábor · 2013. Már. 1. (P), 17.46
Manapság elég egyéni, ha a beléptetés működik javascript nélkül is.
9

Tehát js

Pallosi Péter · 2013. Már. 1. (P), 18.13
Tehát js nélkülözhetetlen?
A feldolgozást mindenképp ajaxxal oldanám meg.
11

Pont az a lényeg, hogy JS

Poetro · 2013. Már. 1. (P), 18.30
Pont az a lényeg, hogy JS nélkül is működjön.
12

Szerinted lehet anélkül

Hidvégi Gábor · 2013. Már. 1. (P), 18.51
Szerinted lehet anélkül biztonságosan?
15

Bár nem tőlem kérdezted,

Pepita · 2013. Már. 1. (P), 20.07
de miért ne lehetne?!
Szerk.: pont a js (kliens oldalon) az, amire én nem bíznék soha semmit, ami biztonsági kérdés.
19

Szerk.: pont a js (kliens

kuka · 2013. Már. 1. (P), 21.25
Szerk.: pont a js (kliens oldalon) az, amire én nem bíznék soha semmit, ami biztonsági kérdés.
Hát úgy elgondolva, hogy
  • Elküldöd a jelszavat úgy, ahogy a felhasználó beírta.
vagy
  • Megkéred a JavaScriptet, hogy számoljon ellenőrző összeget a sózott jelszóból és azt küldöd.
Nekem a második biztonságosabbnak tűnik.
25

Nem értem

Pepita · 2013. Már. 1. (P), 22.36
Lehet, hogy én nem értem - kissé fáradt vagyok -, de ha js-el sózol, hash-elsz, akkor két lehetőség adódik:

1. Aranytálcán odateszed minden látogató gépére a teljes "titkosítási" eljárásod (szerver oldalon ugye u.azt kell csinálnod, hogy u.azt kapjad);
2. Az adatbázisodba "szűz" jelszót tárolsz. Ez még rosszabb, mint az 1.

Szerintem egy oldalnak teljesen működőképesnek kell lennie js nélkül is, legfeljebb néhány kényelmi funkció hiányozhat, de a bejelentkezés távolról sem kényelmi kérdés. (Tudtommal Poetro (is) u.ezen a véleményen van.)

Ha olyan érzékeny dolgokat kap a logolt Júzer, akkor ott a https, egyébként én nem érzem magam felelősnek a látogató hálózatának / kapcsolatának a biztonságosságáért. Ez az ő dolga.

Szerintem manapság sokan túl sok mindent bíznak js-re, pedig nem volna szabad.
29

Bármit is küldenek át kliens

inf · 2013. Már. 1. (P), 23.55
Bármit is küldenek át kliens oldalról, abból még ugyanúgy lehet még egy titkosítási körrel hash-t csinálni...

Szerintem egy oldalnak teljesen működőképesnek kell lennie js nélkül is, legfeljebb néhány kényelmi funkció hiányozhat, de a bejelentkezés távolról sem kényelmi kérdés.


Ez nagyon erősen függ attól, hogy milyen típusú oldalt csinálsz. Pl. egy céges belső oldalhoz nincs szükség openid-re, ill. megkövetelheted a js bekapcsolását is, egy publikus oldalnál meg pont fordítva, hacsak nem alapból olyan az alkalmazásod, hogy js nélkül értelmetlen, vagy túl nagy nehézség lenne összehozni.

Egyébként nekem sokkal szimpatikusabb egy hagyományos webalkalmazáshoz képest az a megközelítés, hogy js-ben tárolom az alkalmazás aktuális állapotát kliens oldalon, a munkamenet pedig a jogosultságokat tartalmazza csak. Az összes session változó kikerül kliens oldalra, nem kell foglalkozni a session.flash() típusú dolgokkal, nem kell history-t vagy az aktuális nyelvet, vagy kosarat tárolni a munkamenetben, és még sorolhatnám. Ezerszer könnyebb így alkalmazást írni.
32

Bármit is küldenek át kliens

Joó Ádám · 2013. Már. 2. (Szo), 17.55
Bármit is küldenek át kliens oldalról, abból még ugyanúgy lehet még egy titkosítási körrel hash-t csinálni...


Amivel máris nagyságrendekkel lerövidítettél egy brute force támadást, effektíve fix hosszúságú, korlátos karakterkészletű jelszavakat kérve be a klienstől. Hashelni egyszer hashelsz, különben kiheréled az egészet.
34

Mondjuk ha 64 karakterből

inf · 2013. Már. 2. (Szo), 20.27
Mondjuk ha 64 karakterből lehet választani, és max 12 a karakterek száma, akkor az összes lehetőség: 64^12 + 64^11 + 64^10 ... 64^3, aminek a vége elhanyagolható, így nagyjából 64^12 lesz a lehetőségek száma, ami 6*12 = 72bit. Egyrészt a hash ennél jóval több biten is lehet, másrészt meg a maximális jelszó hossz, ami számottevő, a kisebb jelszó hosszak hozzá képest elhanyagolhatóak. Még mindig nem értem, hogy mi ezzel a probléma... :-)
35

Amit írsz, azt egyáltalán nem

Joó Ádám · 2013. Már. 2. (Szo), 21.46
Amit írsz, azt egyáltalán nem értem. Én azt mondom, ha mondjuk MD5-tel hasheled a jelszót kliensoldalon, majd ezt küldöd a kiszolgálónak, ahol ismét hasheled, akkor az olyan, mintha a jelszavak hosszát fixáltad volna 32-ben, a használható karaktereket pedig 16-ban. Összesen tehát legrosszabb esetben 16^32 hasht kell végigpróbálni ahhoz, hogy hozzáférést szerezzek egy fiókhoz.
36

Értem, hogy mi mondasz, de

inf · 2013. Már. 3. (V), 05.18
Értem, hogy mi mondasz, de ezt a hatást bizonyos fokig lehet kompenzálni egy hosszabb hash-el.
37

Inkább ne csináljunk ilyet :)

Joó Ádám · 2013. Már. 3. (V), 15.36
Inkább ne csináljunk ilyet :)
40

Próbáltál már végig 16^32

tgr · 2013. Már. 8. (P), 11.09
Próbáltál már végig 16^32 hasht?
41

Fel lennél háborodva, ha a

Joó Ádám · 2013. Már. 8. (P), 15.54
Fel lennél háborodva, ha a jelszavadnak [0-9a-f]{32}-re kellene illeszkednie?
42

Senki nem beszélt arról, hogy

tgr · 2013. Már. 8. (P), 16.04
Senki nem beszélt arról, hogy a user ne használhatna neki tetsző jelszót.
30

Lehet, hogy én nem értem -

kuka · 2013. Már. 2. (Szo), 15.37
Lehet, hogy én nem értem - kissé fáradt vagyok
Vagy az én stílusom sikeredett táviratira. Meg nem is a magyarázataim közérthetőségéről vagyok híres… Ezért talán célravezetőbb volna ha közvetlenül Paul Johnston cikkét, a Protecting Passwordst olvasnád el.
39

Mivel is kezdődik?

Pepita · 2013. Már. 8. (P), 06.13
In general, it is best to use SSL to protect passwords.
Aztán rögtön:
If SSL is used, I recommend that JavaScript hashing not be used - it won't add any security, and could cost you some.
Én csak töröm szpíkelést az angol, mégis úgy látom, hogy ez az én állításaimat támasztja alá, nem a tiédet. A többi a rizsa.
31

Ha aggaszt a szövegesen

Joó Ádám · 2013. Már. 2. (Szo), 17.48
Ha aggaszt a szövegesen küldött jelszó, akkor használj biztonságos kapcsolatot.
38

+1

Pepita · 2013. Már. 8. (P), 06.05
Habár asszem ezt én is javasoltam fentebb.
13

+10

Pepita · 2013. Már. 1. (P), 19.51
Én inkább redirect-et szoktam, oda, ahonnét belogolt. Majdnem úgy, mint itt. Így viszont nem is kell js / ajax.
5

Kezeljen minden fajta

Poetro · 2013. Már. 1. (P), 17.51
  • Kezeljen minden fajta OAuth-ot, pl. Facebook, Twitter, Linkedin, Google, Yahoo.
  • Kezeljen prezisztens bejelentkezést
  • Meg legyen oldva, hogy több szerver között el lehessen osztani a bejelentkezést.
  • Csinálj hozzá saját OAuth felületet, hogy a te bejelentkezésed mások is használhassák
  • Csinálj hozzá egy RESTfull API-t, amivel be lehet jelentkezni
  • Korlátozd a belépési próbálkozások számát percenként / óránként
  • Elfelejtett jelszó implementálása token segítségével, ami meghatározott idő múlva lejár
7

Kifejtés

Pallosi Péter · 2013. Már. 1. (P), 18.12
Van kettő dolog amit érdekesnek vélek felfedezni kifejtenéd nekem ezt a kettő dolgot?
Kezeljen minden fajta OAuth-ot

Meg legyen oldva, hogy több szerver között el lehessen osztani a bejelentkezést

Ennyi lenne és még lenne egy kérdésem,hogy ez mit takar?
Csinálj hozzá egy RESTfull API
8

Járj utána

Poetro · 2013. Már. 1. (P), 18.13
Járj utána
10

Korrekt.

Pallosi Péter · 2013. Már. 1. (P), 18.14
Korrekt válasz.
Ha kész a felület publikálhatom?itt?
14

Poetro, plussz

Pepita · 2013. Már. 1. (P), 20.04
Amit Poetro már leírt, azt nem ismétlem. Azon kívül:
  • Jogosultságok, felhasználói csoportok
  • Nem automatikus (admin beavatkozáshoz kötött) regisztráció lehetősége
  • Bejelentkezett Júzernek nem változhat meg az IP-címe


Publikálással kapcsolatban vedd fel a kapcsolatot a szerkesztőkkel, ha egy komoly és jó cuccost csinálsz, én kíváncsi lennék rá pl. cikk formában. Ehhez viszont nagyon jó (és szép) kódot illik írni, valamint szépen fogalmazott és szerkesztett kísérőszövegeket (helyesírási hibák nélkül).
16

haha

Pallosi Péter · 2013. Már. 1. (P), 21.11
benyújtom a diszgráfia papiromat :-):-):-)
23

Kevés!

Pepita · 2013. Már. 1. (P), 21.49
Attól még - szerintem - semmivel sem lesznek türelmesebbek a szerkesztők... :) Talán néhány sör többet ér. :)
24

Sör.

Pallosi Péter · 2013. Már. 1. (P), 22.15
Fúj nem a sör az nem pia inkább kóla :)
26

Hé-hé, nem neked!

Pepita · 2013. Már. 1. (P), 22.43
Félreértetted: neked nem meginni kell, hanem küldeni a cikk mellékleteként! :)
Egyébként egy szerkesztőről biztosan tudom, hogy eléggé szereti a sört (legalábbis sokat meg tud inni), de nem árulom el kilétét. :)

Szerk.: ha én szerkesztő lennék, most a kólás állásfoglalásért legalább két hétre letiltanálak. Szerencséd, hogy nem vagyok... :):)
27

Egy szép tavaszi este

Hidvégi Gábor · 2013. Már. 1. (P), 22.46
Egy szép tavaszi este megismételjük. De most olyan helyet keresünk, ami nem zár tízkor : )
28

Másnap

Pepita · 2013. Már. 1. (P), 22.58
És nincs másnap Webkonf / egyéb, hanem nyugodt lélekkel lehet Másnap. :)
33

Kemény konf volt, nagyon

Joó Ádám · 2013. Már. 2. (Szo), 17.57
Kemény konf volt, nagyon kemény.
44

2014-ben már nem életszerű...

Max Logan · 2014. Feb. 8. (Szo), 13.18
..., hogy a „Bejelentkezett Júzernek nem változhat meg az IP-címe”.

Mondok egy ma már teljesen szokványos munkamenetet. Otthon vagyok vonalas netet használok. El kell mennem egy megbeszélésre, viszem magammal a notebook-ot. A partnernél az ő WiFi-jét használom. Hazafelé beülök egy kávézóba, ahol megosztom a telóról a netet és úgy netezek a notebook-on.

Ez legalább 3 IP cím akár néhány óra leforgása alatt...
45

Nap közben

Poetro · 2014. Feb. 8. (Szo), 13.22
Nekem nap közben legalább 4 IP címet használok onnantól kezdve, hogy felkeltem odáig, hogy beérek a munkahelyre, és mindet ugyanazon a telefonon. Reggel otthoni Wi-Fi-n bejelentkezek, elindulok munkába, a metrón előbb 3G-t használok, majd mikor elérhetővé válik, akkor a metro Wi-Fi-jére kapcsolódom (London). Mikor leszállok, akkor ugye újra vissza 3G-re, majd mikor beérek a munkahelyre, akkor a munkahelyi Wi-Fi. És közben csak 1 óra telt el, és legalább 3-szor változtattam hálózatot és IP címet.
17

Én pont most tákolok egyet,

inf · 2013. Már. 1. (P), 21.18
Én pont most tákolok egyet, mondjuk az csakis REST-es alkalmazásokhoz készül, nem ennyire általános. Ha gondolod átküldöm, amint elkészült.
18

megtisztelő

Pallosi Péter · 2013. Már. 1. (P), 21.24
megtisztelő lenne egy profi kódját tanulmányozni.
megcsináltam az email küldést.
20

Jó vicc :D Én is nagyon

inf · 2013. Már. 1. (P), 21.31
Jó vicc :D Én is nagyon messze vagyok a profitól... Felszórom majd github-ra, aztán küldök linket. Jövő héten valamikor elkészül.
21

remek

Pallosi Péter · 2013. Már. 1. (P), 21.36
:-)
22

Ide linkeljed

Pepita · 2013. Már. 1. (P), 21.47
Jó helye lenne itt (is) későbbi olvasóknak, stb., én is szívesen megnézném (cikk?). Vannak nagy különbségek a szemléletmódunkban, de nemrég én is csináltam ilyet, és még nem eléggé kiforrott -> most(anában) kellene egész más szemszögből is megnézzem u.azt, mondjuk pont a te szemszögedből...
43

Nem felejtettem el, csak

inf · 2013. Ápr. 30. (K), 07.45
Nem felejtettem el, csak azóta beolvaszottam a kódot egy alkalmazásba. Amint kész leszek a teljes alkalmazással, és lesz időm, ki fogom emelni ezt a részt.