Kezdőoldal » Számítástechnika » Programozás » Felhasznalo jelszava helyi...

Felhasznalo jelszava helyi fajlban titkositva megfelelo-e?

Figyelt kérdés

Egy alkalmazast irok programozo gyakornokkent, most vagyok tul a tervezes nagyjan (MVC), es a kod is meg van nagyvonalakban.


A desktop alkalmazas (C#) lehetove tenne a felhasznalonak, hogy kenyelmi okokbol mentse a jelszavat egy helyi meghajton levo fajlba (userdata fajl), ehhez AES/Rijndael algoritmussal titkositanam a jelszot es ugy tarolnam, majd a kovetkezo programinditaskor (ugyanazzal a kulccsal es init. vektorral) feloldanam a titkositast es ezzel "jelentkeztetnem" be a felhasznalot az adatbazis szerveren.


2 kerdesem van:


1) Elegendo biztonsagot jelent-e ez a megoldas a helyi userdata fajl ellopasa eseten?

2) Kell-e titkositanom-e a connection string tobbi elemet, pl. az adatbazis szerverenek cimet vagy a felhasznaloi nevet?



#adatbázis #jelszó #titkosítás #AES #Rijndael #felhasznaloi adatok #helyi lemezen valo tarolas
2013. aug. 9. 04:38
1 2 3 4
 1/36 SimkoL ***** válasza:
12%

A felhasználó nevet és a jelszót mindenképpen. Az adatbázishoz való kapcsolódás többi elemét felesleges mivel azt többen is használ(hat)ják.

Bár én a titkosításra egyedi algoritmust írnék :)

2013. aug. 9. 06:09
Hasznos számodra ez a válasz?
 2/36 A kérdező kommentje:

Koszonom a valaszt,


sajnos egyelore nincs idom sajat titkositasi algoritmus kifejlesztesere, valoszinuleg a .Net Frameworkkel "keszen kapott" System.Security.Cryptography.RijndaelManaged osztaly helybol messze jobb, mint ami en neki futassal produkalni tudnek valaha is :)

2013. aug. 9. 06:51
 3/36 anonim ***** válasza:
100%
De ha a userdata fájlt el tudják lopni, akkor hogyan véded meg, hgoy az exe-det ne tudják ellopni? Hiszen abban van a kulcs, akkor semmit nem ér a titkosításod.
2013. aug. 9. 09:15
Hasznos számodra ez a válasz?
 4/36 A kérdező kommentje:
@2: Ez tenyleg igaz, van lehetoseg annak kivedesere, hogy az .exe es a userdata file egyuttes "ellopasa" eseten kivedjem az illetektelen hozzaferest?
2013. aug. 9. 09:27
 5/36 anonim ***** válasza:
100%

Ha a futtatási környezet valamely, egyszerre állandónak és egyedinek tekinthető paraméterei alapján kiszámítasz egy sót a titkosítókulcshoz, az megakadályozza/-hatja, hogy más környezetben, az EXE és a userdata fájl együttes birtokában, a titkosítás feloldható legyen. A salt használata amúgy is kvázi kötelező :)


Szabadjon megjegyeznem, hogy mentett jelszavak esetén semmi sem garantálja a biztonságot.


A többi stringet is illik titkosítani, hogy egy esetleges támadónak a lehető legkevesebb támpontot szolgáltasd a biztonsági intézkedések megkerüléséhez. Bonyolíthatod a kommunikációt SSL/HTTPS/rózsabimbó alatt...

2013. aug. 9. 09:49
Hasznos számodra ez a válasz?
 6/36 anonim ***** válasza:

#5 Igen, ez megakadályozza első lépésben.


Viszont ekkor a "tolvaj" azt tudja tenni, hogy elviszi az exe-t.

Otthon megvizsgálja a programot, ír egy olyan programot, ami kiszámolja ugyanezt a sót. (Igazából nem is kell sajátot írni, mivel .NET-es programról van szó, elég egyszerűen le tudod futtatni bármely private metódusát, azaz ami a sót számolja azt is...akár saját kódból, akár reflecor+smoketest-tel, akár reflector+reflexillel picit módosítod, hogy egy msgboxban megmutatssa)


Visszamegy a géphez, ahol a cucc van. Lefuttatja a programját, és viszi a sót és a userdata-t.


Ha a gépen ahol a program fut a "tolvaj" adminisztrátori jogokkal rendelkezik, akkor semmit nem tudsz ellene tenni. Ha nem admin, akkor már jobbak az esélyeid.

2013. aug. 9. 10:01
Hasznos számodra ez a válasz?
 7/36 anonim ***** válasza:
100%

#6 Ilyen ez a popszakma. 100% -os biztonság nincs, nem is lesz. Mentett jelszót megvédeni komoly támadóval szemben gyakorlatilag esélytelen, viszont a hozzáférés megnehezíthető oly mértékben, hogy a legtöbb próbálkozónak ne érje meg.


BTW ott van a Chrome, vagy a Firefox, mint nyílt forrású szoftver, ami rendelkezik ilyen funkcionalitással. Bele lehet nézni, hogy ők hogyan oldották meg a problémát.

2013. aug. 9. 10:08
Hasznos számodra ez a válasz?
 8/36 iostream ***** válasza:
75%

Ahogy többen mondták már, mentett jelszó sosem lesz biztonságos, de jó tippeket adtak a biztonság fokozására.

Simkol meg hülye, ne hallgass rá. A saját algoritmus két dologra jó: sok időt visz el, és semmit nem tudsz a tényleges biztonságáról. De semmiképp nem javítja a biztonságot. Alapvetős ebben a témában, hogy az algoritmust ismertnek kell feltételezni, főleg egy .net-es program esetén halál lazán visszafejtik, de natívból is ki lehet szedni.

2013. aug. 9. 10:35
Hasznos számodra ez a válasz?
 9/36 A kérdező kommentje:

Koszonom a valaszokat, mentek a zold mancsok. Sajnos nem tudok nagyon sok idot a biztonsag kialakitasara forditani, ami persze nem mentseg, de megjegyzem, a masik alkalmazas elozo verzioja, aminek az ujrairasan dolgozok mindenfele titkositas nelkul tarolja egy szimpla txt fajlban a jelszot ugy hogy: Password=jelszo Elotte pedig a connection String osszes eleme Host, Database, User... :D


A fonokeim, bar maguk is mernokok, abszolut nincsenek kepben a temaban, nekik csak az a lenyeg, hogy szepek legye a grafikonok es lehetoleg 1 het alatt kesz legyen... Mar azert is gyanusan neznek ram, ha csak ceruzaval UML-t rajzolgatok egy A4-es lapra, kozben minden mernokszakma alapveto resze a pontos es reszletes tervezes. Szoval ilyen a gyakorlatom, a Firefox megoldasara kivancsi vagyok es utananezek, kulon koszonom ezt a tippet.

2013. aug. 9. 12:50
 10/36 iostream ***** válasza:
31%
A programozás még nagyon erősen nem mérnöki szakma. Nincs meg a többszáz éves múltja neki. Nem alakultak még ki azok a szokások, gyakorlatok amik egy rendes mérnöki szakmánál. De igen, fontos a tervezés, bár nem feltétlenül UML szinten, az már túl alacsony (az UML -> C# átalakítás egy nagyon vékony dolog ezek után).
2013. aug. 9. 13:25
Hasznos számodra ez a válasz?
1 2 3 4

Kapcsolódó kérdések:





Minden jog fenntartva © 2024, www.gyakorikerdesek.hu
GYIK | Szabályzat | Jogi nyilatkozat | Adatvédelem | Cookie beállítások | WebMinute Kft. | Facebook | Kapcsolat: info(kukac)gyakorikerdesek.hu

A weboldalon megjelenő anyagok nem minősülnek szerkesztői tartalomnak, előzetes ellenőrzésen nem esnek át, az üzemeltető véleményét nem tükrözik.
Ha kifogással szeretne élni valamely tartalommal kapcsolatban, kérjük jelezze e-mailes elérhetőségünkön!