Felhasznalo jelszava helyi fajlban titkositva megfelelo-e?

@iostream: De, mérnöki munka függetlenül attól, hogy annyira még nem régi, illetve bizony fontos a tervezés UML szinten is.

Legalábbis annak, akkor tényleg rendes munkát akar végezni.

Bár a 2 kérdésre már lett válasz, de azért én is hozzáteszem, hogy valóban nem érdemes a lokális gépen annyira rámenni a titkosításra, főleg, ha a kulcs statikus, mivel ha magát az állományt ellopják, akkor a kulcsot is el tudják. (Plusz C# esetében nevetségesen könnyű a forráskódhoz visszajutni.)

Bár azért valami minimális dolog nem árt rá, hogy ha már, akkor ne cleartextben legyen ott a jelszó és minden adat egy txt-ben.

Erre egy base64, vagy rot13 is bőven elég.

Védelemnek ez nem védelem, de legalább aki csak úgy unalmában belenéz a fájlba, nem fogja az arcába kapni az összes jelszót.

Én nem értek hozzá, de több évet dolgoztam a 'cég'-nél rejtjelzőként. Egyedi algoritmus - ez is feltörhető mint minden - de legalább 'munkát' ad a tolvajnak. Sok ötletem van, de nem teszem nyilvánossá :)

A titkosítás, rejtjelzés már szinte az írás 'felfedezésétől' létezik, bármilyen primitív módon is.

Most elég fáradt vagyok, de holnap dobok fel egy exe file-t ami jelszót kér. Feles - sör - parasztgyerek vagyok állom a szavam - aki 48 órán beül visszaküldi privátba a jelszót.

Van aki benne van ?

Ennyiért nem éri meg ezzel szórakozni szerintem.

De az a gond az "új" algoritmusokkal, hogy nem lehet eleget tesztelni.

Lehet, hogy baromi jónak tűnik, de aztán hamar kiderülhet, hogy pillanatok alatt ki lehet nyitni.

"Ennyiért nem éri meg ezzel szórakozni szerintem. "

Na látod itt a lényeg. Ha az ismert titkosítási eljárások alapján nem sikerül feltörni nem biztos, hogy valaki időt fordít rá, hogy kínlódjon vele.

1986-ban tettem rejtjelző vizsgát a Belügyminisztériumban. Akkor még nem voltak komoly számítógépek én az ősi dolgoktól kezdve tanultam meg mindent. Ha titkosítani kell valamit saját elgondolásom szerint készítem el régi alapokkal új köntösben :)

Nem mondom, hogy nem lehet megfejteni, de lényegesebben több időt, energiát kell belefektetni, mint az ismertekbe.

...és akkor megin ott vagyunk" Ennyiért nem éri meg ezzel szórakozni szerintem. "

Abból indulsz ki, hogy nem ismerik a kódot. Ez hibás feltételezés, tedd fel, hogy ismerik a kódodat, és utána vizsgáld meg a biztonságosságot. Ez persze nem minden esetben lesz így, de aki tényleg akarja, annak meglesz.

"@iostream: De, mérnöki munka függetlenül attól, hogy annyira még nem régi, illetve bizony fontos a tervezés UML szinten is.

Legalábbis annak, akkor tényleg rendes munkát akar végezni."

Ezzel nem tudok mit kezdeni. Oké, akkor emellett még kígyóuborka is, ha már alapozás nélkül akarunk dolgokat állítani. Az UML szintű tervezés meg itt egyszerű osztálydiagramokat jelent, azoknak igazából tervezéskor sok értelme nincs, ugyanis 1:1 ültethetők át kódra, vagyis ekvivalensek a kóddal. Inkább a kódbol szoktuk kinyerni dokumentációnak.

"Inkább a kódbol szoktuk kinyerni dokumentációnak."

Épp elég baj az. :)

Pont ez a lényeg, hogy könnyen implementálható már és nem utólag derülnek ki még dolgok, ami miatt át kell írni a teljes programot.

Sőt, ennél még lehet tovább menni, illetve ezzel párhuzamosan jöhet az a megközelítés, amikor a tesztek is a kód megszületése előtt készülnek el.