Hello
jelszavakat kell taroljak olyan formatumban hogy az vissza alakithato legyen az eredeti formajara
(tudom hogy ez veszelyes de valami okbol ez most igy kell)
milyen programozasi megoldast javasolnatok hogy ha netan feltorik es ellopjak az adatbazist es a php kodot akkor is kis eselyel keruljenek ki a jelszvak
a rendszer egy ubuntu 16.04 es vps -en fog futni, php7 ben lesz irva az applikacio es mysql ben lesznek az adatok
En csak azt a megoldast ismerem hogy el encrypt -alom egy kulcs al ami a weboldal configban (php ban) van es ugy irom be az adatbazisba
de ha valaki feltori a rendszert es elviszi a php kodot es az adatbazist is akkor kikerulnek a jelszavak
szoval esetleg van e valami hasonlo megoldas amivel ezt lehet neheziteni
pl: valami rejtett funkcio a linux on belul amivel pl az a decrypt csak arrol a geprol fut le helyesen es ha masol
akarjak lefuttatni a kodot akkor mar nem jo eredmenyt ad nekik vissza
vagy egy specialis webszerver beallitas vagy ilyesmi amivel csak azon a gepen lehet helyesen kiolvasni a jelszavakat
koszi a valaszokat elore is
- 2116 megtekintés
Hozzászólások
Az crypt es mysql-ben az encrypt az egyiranyu, marmint a fuggenyek. Ketiranyut a kulon php pluginnel tudsz, de ahhoz a mesterkulcsot tarolnod kell valahol. Ez raadasul kulon serulekenyseg, mert nem csak a jelszavak kikerulese, hanem a juzerek legalabb idoleges kizarasa is konnyu.
En mindenkepp afele terelnem a kedves megbizot, hogy a jelszavakat egyiranyban titkositsa a rendszer. Ha valamilyen account belenezesi opcio kell akkor sem a jelszo visszafejtese, hanem valami specialis session a megoldas, amivel a juzer neveben lehet ugykodni.
- A hozzászóláshoz be kell jelentkezni
Kétkulcsossal. Publikussal kódolsz, azt beírod az adatbázisba, ahhoz vizsgálod pl. bejelentkezéskor. Ha dekódolni kell, akkor a saját gépeden a privát kulccsal dekódolod. Természetesen a privát kulcsot nem tartod a szerveren, különben megette a fene.
Ha emberi beavatkozás nélkül, tisztán az adott szerveren kell dekódolhatónak lennie, akkor a kérdésedre a válasz: sehogy.
- A hozzászóláshoz be kell jelentkezni
Így végülis duplán tárol, de hát szóval nem lennék nyugodt egy ilyentől se. Mondjuk választ egy 1024 bites kulcsot, de az 3-4 év múlva kutyafüle lesz és egyszerűen nyitják kikerüléskor. Bár ez igaz a hash-ekre is sajnos.
- A hozzászóláshoz be kell jelentkezni
Nem tárol duplán.
Egyébként meg használjon 4096 bites kulcsot, és legyen kötelező negyedévente a jelszócsere.
(Bár én sem tudom, hogy ez az egész mire jó.)
- A hozzászóláshoz be kell jelentkezni
Hááát végülis. Jó rövidek lesznek a mezők. :)
- A hozzászóláshoz be kell jelentkezni
Ha úgyis vissza tudja fejteni a jelszavakat, akár automatikusan is migrálhat 2 évente :-D
Fuszenecker Róbert
- A hozzászóláshoz be kell jelentkezni
koszi ennek utanna nezek
- A hozzászóláshoz be kell jelentkezni
Az alább kifejtett „mas rendszerekhez kell csatlakozni olyanokhoz ami felett nem en vagyok az admin” mondatod alapján ez nem fog menni.
Viszont az egész elképzelés arra jó, hogy a te biztonsági szintedtől teszed függővé más(ok) rendszerét. Ez nagyon nem jó megoldás, bármily nemes is lenne a cél.
- A hozzászóláshoz be kell jelentkezni
Pontosan ugyanez jutott eszembe (a PK is és a "sehogy" is :-)).
Fuszenecker Róbert
- A hozzászóláshoz be kell jelentkezni
Félig off, de erre szokták mondani, hogy nem egy problémára keresel megoldást, hanem a problémádra kitaláltál egy rossz megoldást, és abban kérsz segítséget. Mi az eredeti probléma? Biztos az én fantáziám ilyen szegényes, de el nem tudom képzelni, miért kell neked tudni a jelszavakat a jelszó ellenőrzés idején kívül. Ez utóbbi fontos kitétel, tehát ha pl. a jelszót szinkronizálni akarod máshova, akkor bőven elég azt belépéskor vagy jelszó módosításkor megtenned, nem kell hozzá eltárolni.
- A hozzászóláshoz be kell jelentkezni
a te fantziad szennyes
mas rendszerekhez kell csatlakozni olyanokhoz ami felett nem en vagyok az admin
- A hozzászóláshoz be kell jelentkezni
az nem játszik, hogy amikor ezekhez a más rendszerekhez kell hozzáférni, akkor mondjuk munkamenetenként egyszer újra bekéred a jelszót a usertől? Ha már muszáj tárolni, ne tárold permanensen...
- A hozzászóláshoz be kell jelentkezni
vagy amikor a user bejelentkezik es megvan a plain jelszo egyebkent is, letrehozza a jelszoval a sessiont a tavoli oldalon is
// Happy debugging, suckers
#define true (rand() > 10)
- A hozzászóláshoz be kell jelentkezni
SSO nem jatszhat?
Egyebkent a tavoli rendszerek gazdaival erdemes beszelni, hogy ok minek orulnek, es minek nem. Meg lehet uszni egy kis hisztit.
- A hozzászóláshoz be kell jelentkezni
SSO, hahaha :)
Ismerek olyan hülye külföldi multit, ahol a SINGLE SIGN ON azt jelenti, hogy minden rendszerbe csak 1x kell különböző accounttal hitelesíteni. Mindenki eméssze meg a mondatot...
--
WP8.x kritika: http://goo.gl/udShvC
- A hozzászóláshoz be kell jelentkezni
mas rendszerekhez kell csatlakozni olyanokhoz ami felett nem en vagyok az admin
Na akkor az a kérdés, hogy ezek a más rendszerek milyen olyan authentikációt támogatnak, amihez vagy nem kell jelszó, vagy a jelszóról tudja a másik rendszer, hogy csak innen szabad használni (ergó, ha ellopják, nem tudnak vele bejelentkezni, mert a másik rendszer nem fogja beengedni).
Ha ezekre az a válasz, hogy ilyet a másik rendszer nem tud, mezei clear text jelszót kell neki küldeni, és ha azt ellopják, akkor gáz van - no ebben az esetben nagyjából kijelenthető, hogy nincs normális megoldás a problémádra. Az igazán elvadult hacker ugyanis a programod memóriájából egészen biztosan ki tudja olvasni az éppen használt clear text jelszavakat (bárhogyan is tárolod azokat titkosítva), ergó amíg nem veszitek észre, hogy feltörték a rendszert, biztosan tudja nyúlni az éppen használt jelszavakat.
- A hozzászóláshoz be kell jelentkezni
" valami rejtett funkcio a linux on belul amivel pl az a decrypt csak arrol a geprol fut le "
Abból indultunk ki, hogy "ha valaki feltori a rendszert es elviszi a php kodot es az adatbazist is". Ha valaki megteszi, akkor a decryptet is letudja onnan, nemde?
De legyek konstruktív, és főzzek abból, ami van - tételezzem fel, hogy csak annyi ideje van a csufipofának, hogy elvigye a kódokat és az adatbázist!
Akkor ne akarjon a php kódolni és dekódolni, hanem adja ki a munkát egy másik processznek (lehetőleg másik gépen), amely processz annak és csak annak a gépnek szolgáltatja ki a kódolt/dekódolt jelszót, amit neki megmondtak. Sőt, ha adott idő alatt adott maximumnál több jelszó átdolgozását kérik tőle, beint, lehúzza a rolót, és SOS-t küld.
De az alapok folytán bármit fűzünk hozzá, ez már nem lesz más, csak https://en.wikipedia.org/wiki/Security_through_obscurity és abból is csak az obscurity biztos.
- A hozzászóláshoz be kell jelentkezni
ja egy masik gep az jo otlet
eselyes megoldas
lehet hogy ket kulon chroot olt szerviz kellene
mivel azt gondolom hogy nem ssh -n keresztul fogjak feltorni ha nem valahogy esetleg a php ban talalnak valami rest
igy ha a webszerver es a "kulcs szerver" kulon kornyezet akkor szerintemnagyban javulnak az eselyek
masreszrol pedig nem hiszem hogy egy feltoresnel az egesz linux ot lemasoljak csak fogjak az adatbazist es a php kat tartalmazo mappat es elfutnak vele
legalabbis en nem a szerveren kezdenem el dekodolni hanem lementenem minel hamarabb a lenyeget
- A hozzászóláshoz be kell jelentkezni
Itt azt ígérik, h olvashatatlanná, visszafejthetetlenné lehet tenni a PHP kódot (nyilván a decryptelődet) és a lefutását is lehet vele korlátozni időben, v. hálózati szegmensre (persze nem ingyért):
http://www.zend.com/en/products/zend-guard
(mondjuk a 7-es verzióval nem biztos h műxik)
- A hozzászóláshoz be kell jelentkezni
Ahogy már előttem is mondták: kétkulcsos titkosítás. A publikus ott lehet a szerveren, akár el is vihetik, nem gond. A jelszót ezzel titkosítva tárolod - amikor az user belép, akkor az általa megadott jelszót is ugyanígy titkosítod, majd megnézed, egyezik-e a tárolttal? Ha igen, jó a jelszó, ha nem, akkor sorry - viszont ehhez nem kell a privát kulcs. Ha tehát bármi miatt mégis kell az eredeti jelszó, akkor a tárolt kódolt jelszót átviszed egy tuti biztonságos gépre és az ott létező, onnan soha ki nem kerülő privát jelszóval előveszed az eredeti jelszót és használod (titkos) céljaidra.
Ha ez a csavar, hogy elő tudd venni az eredeti jelszót, azért kell, mert más rendszerekkel is együtt kell tudni működni, akkor gondolj arra, hogy kiscsillió helyen megoldották, hogy lépj be a kugli/arcköny/MS azonosítóddal - és ekkor nem kel szórakozni az authentikáció megvalósításával. Persze ehhez kell, hogy az usernek legyen ilyen accountja - de ha jól tévedek, akkor van ilyen megoldásokra nyílt kód is, tehát legfeljebb közös authentikációt kell használni és annyi. Gondold át azt is: mi van, ha az user jelszót cserél? Ez akkor hogyan fog átkerülni a többi rendszerre? Macera. Sokkal tisztább egy központi authentikációs megoldás, amit az összes rendszeretek használ.
Persze nyilván csak kibiccelek - annyi infóval, amennyit adtál. Tehát ha vannak egyéb, általam nem ismert peremfeltételek, akkor azok keresztül húzhatják a javaslatot.
- A hozzászóláshoz be kell jelentkezni
letezik ilyen feladatra hardveres modul.
en igy csinaltam: kulon gep ugyanazon a belso halozaton (csomo szolgaltatonal lehet igy berelni gepet nekem 7eur/ho egy ilyen)
Ez a gep semmi mast nem tud csak jelszot szolgaltatni. semmi egyeb nem fut rajta.
Mindossze egy watchdog van benne ha nem pingelik idoben, akkor bezarja sajat magat es nem ad ki tobb jelszot.
Nagyon fontos a rate limit, igazabol mindent limitalni kell.
Indulaskor ket jelszo kell neki, egyet az infrastrukturabol kap, egyet meg tolem. (2x van csomagolva a jelszo amivel nyitja sajat magat)
A megszerzett mesterjelszo a nemoriaban van(egy valtozo), amit el tud felejteni, ha kell.
Meg annyit tud ez a gep, hogy statuszt lehet tole kerdezni, es ha gebasz van akkor sms-t kuldd nekem a statusz lekerdezo kulon kis szerver(docker kontener)
Szerintem egy kicsit paranoia lett, mrg a hatdveres megoldas talan jobb is lenne, csak nibcs infrastrukturam...
---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
- A hozzászóláshoz be kell jelentkezni
Egy újabb rossz ötlet (fentebb többen írták, hogy inkább a problémát írd le, hogy jó megoldást is tudjunk adni, ne csak azt, hogy te hogyan gondoltad megoldani), partszélről bekiabálva, de elvileg működhet... Ha csak akkor van szükséged a user jelszavaira, amikor hozzád is be van lépve, akkor működhet ez (ha pl. cronból akarod őket megszemélyesíteni, az bukó)
Minden usernek generálsz egy kulcspárt, aminek exportáláskor beállítod a passphrase-ét a user jelszavára (ha meg jelszót vált nálad, akkor újra exportálod a kulcspárt az új jelszót beállítva passphrase-nek). A kulcspárt mented a db-be. Amikor egy user beállítja/módosítja valamelyik külső szolgáltatáshoz tartozó jelszavát, akkor a publikus kulcsával kódolod és mented az adatbázisba, ha pedig szüksége van rá, akkor a privát kulcsával dekódolod. Így amikor éppen nincs aktív session-je egy usernek, akkor nem tudod a jelszavát (így a privát kulcsa passphrase-ét sem), úgyhogy nem férsz hozzá a jelszavaihoz.
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
- A hozzászóláshoz be kell jelentkezni
nem irtam le viszont valoban csak akkor van szukseg a mentett jelszora amikor az adott user belep
talan ez eddig a leg kivitelezhetobb megoldalas es a kulcs sincs a gepen elmentve mert csak akkor jon letre amikor az user belep
valami ilyen otletre vartam
koszi
- A hozzászóláshoz be kell jelentkezni
Az nem jatszik, hogy a hitelesitest az egyeb szerver vegzi es neked csak session-be visszaadja hogy az user hitelesitett-e vagy sem?
Nalunk egy belso PHP's portal nem csinal mast csak a bejelentkezo informaciot elkuldi az AD szervernek,ha a domain\user+jelszo megfelelo, akkor kapok egy OK't ha nem, akkor nem. innentol nem is kell tarolnom a jelszot semmilyen formaban.
- A hozzászóláshoz be kell jelentkezni
Több bajom van ezzel a dologgal:
-A biztonság ebben az esetben feláldozható dolog
-Átveszel szerepköröket a másik rendszertől. Erre a problémára nekik kellene megoldást adni, vagy legalábbis kooperálni
-Átveszel felelősséget. Ha feltörik egy user fiókját, és óriási károkat okoznak az idegen rendszerben, hogy bizonyítod be, hogy nem téged törtek fel, és lopták el az adatait?
- A hozzászóláshoz be kell jelentkezni
Bár a jelszó visszafejtést nem tartom jó ötletnek, de az alábbi függvényeket érdemes tanulmányozni:
https://secure.php.net/manual/en/function.gnupg-encrypt.php
https://secure.php.net/manual/en/function.gnupg-decrypt.php
Ezenkívül ha a máshova történő beléptetésre van szükség, akkor megoldás lehet az adott munkamenetbe valamiféleképpen eltárolni a júzer adatait, és az alapján beléptetni a külsős szájtra.
- A hozzászóláshoz be kell jelentkezni
Valamilyen HSM, hardveres tikosítás szóba jöhet?
Például egy USB-s:
https://www.yubico.com/products/yubihsm/
Sakk-matt,
KaTT :)
- A hozzászóláshoz be kell jelentkezni
"valami rejtett funkcio a linux on belul amivel pl az a decrypt csak arrol a geprol fut le helyesen es ha masol
akarjak lefuttatni a kodot akkor mar nem jo eredmenyt ad nekik vissza"
A rejtett funkció egy gépbe illeszthető hardware lesz, minden jelszó-hozzáféréskor ide fordul az alkalmazás.
- A hozzászóláshoz be kell jelentkezni
Pontosan erre a problémára megoldás az SSO. Beszélni kell a másik rendszerek üzemeltetőivel.
Szinte biztosra mondható, hogy nem örülnének ha tudnák, hogy visszafejthetően eltárolja valaki a jelszavakat.
Nem érdemes ilyeneket bevállalni. Simán elképzelhető, hogy felhasználói feltételekkel is ütközik egy ilyen rendszer és jogi problémák elhetnek belőle.
- A hozzászóláshoz be kell jelentkezni