Zabezpieczenie plików class

Witam!

Jaki sposób na zabezpieczenie plików class polecacie? Jest to dość ważne ponieważ nie wyobrażam sobie aby ktoś czytał kod wraz z hasłami do bazy danych MySQL, albo do innych połączeń.

W jaki sposób to zatić? W przypadku aplikacji EXE to można kompresować, używać jakiś mało popularnych programów do tego celu i tak dalej, ale co w przypadku Apletów na strony www? Jak zapobiegać dekompilacji class?

Są programy robiące z :

btnNew = changeButtonLabel(btnNew, language.getText("new"));
btnOpen = changeButtonLabel(btnOpen, language.getText("open"));

to:

d = a(d, n.a("new"));
e = a(e, n.a("open"));

Czyli jak mam hasło w cudzysłowie to nie zostanie ono zaszyfrowane prawdopodobnie, a zależy mi na bezpieczeństwie, bo w innym wypadku każdy będzie mógł dostać się do bazy.

Macie jakieś pomysły? De fako 100% zabezpieczenia nie ma... choć w przypadku kluczowych zmiennych powinno się w jakiś sposób uniemożliwić praktycznie w 100% dekompilacje fragmentu tekstu.

Pozdrawiam

Przede wszystkim zapomnij o trzymaniu jakichkolwiek haseł w kodzie. Takie "zabezpieczenie" jest nic nie warte, nawet gdyby te hasła były poprzerabiane różnymi wymyślnymi funkcjami zawartymi w tym samym kodzie. Jedyne naprawdę skuteczne zabezpieczenie, to stworzenie własnego loadera zaszyfrowanych klas, który te kluczowe będzie pobierał z serwera. A aby się do niego dostać hasło takie musi podać user (np. z palca). Krótko mówiąc najlepiej zabezpieczony kod to taki, którego po prostu nie ma. Oczywiście z paczkach z dystrybuowanym softem można wrzucić klasy o tych samych nazwach z zawartością robiącą nic lub jakiś totalny nonsens z dużą ilością skomplikowanych obliczeń (cokolwiek co zajmie crackerowi lata analizy - najlepiej silnie powiązane z bezpośrednimi danymi zabezpieczanego softu).
Żeby zrobić własny loader musisz przede wszystkim wyłączyć w locie kompilator hot-spot, o czym zapomina wielu amatorów - wtedy rezygnują z tego rozwiązania sądząc, że mechanizm dynamicznego ładowania klas zwyczajnie nie działa (Spowolni to działanie kodu o ok. 6 razy, ale prędkość w sekcjach krytycznych nie jest aż tak ważna jak uzyskana funkcjonalność).
Oczywiście dynamicznie ładowane zaszyfrowane klasy mogą po uruchomieniu również wprowadzać dalsze poziomy zabezpieczeń oparte na tym samym lub zupełnie innym mechanizmie. Na przykład zabezpieczenie może bazować na zależnościach czasowych - opóźnienia działania kodu mogą spowodować wypuszczenie od strony serwera kolejnej wersji klasy typu fake. Tradycyjnie ilość poziomów zabezpieczeń jest ograniczona tylko stopniem paranoi zabezpieczającego. :)
Rozbudowany schemat tego typu to nic innego jak DRM (lub zabezpieczenia współczesnych gier sieciowych).

Więc nie będzie łatwo. A jakiś inny pomysł na pobieranie haseł, danych z sieci? prócz loadera? No bo w jaki inny spsób mam łaczyć się z bazą danych? jak mi to zdekompilują i bazę zjedzą :)

Nasuwa mi się jeden pomysł na zabezpieczenie -> Użytkownik w aplecie wpisuje hasło, a aplet pobiera i wysyła dane do plików php np. http://example.com/file.php?login=jakis&haslo=jakies&p1=costam&p2=costam2

Wiem że nie jest to dobre rozwiązanie, ale nie będą to na tyle istotne dane, a po drugie lepsze to niż zapisane hasła do bazy danych mysql.

Z tym że i tak muszę mieć jedno hasło zapisane (nie do mysql, a do innego serwera), w aplecie...

Istotne jest to, żeby wszystkie rodzaje haseł czy dostępów wynikały z przetworzenia hasła (lub dowolnego innego klucza) podanego przez użytkownika. Przy takim założeniu nie potrzebujesz zaciemniać kodu klas bo nikomu nic nie da posiadanie nawet wszystkich źródeł (tak samo jak posiadanie źródeł Linuksa nie daje Ci dostępu do niczego w takim systemie). Czasem trzeba jedno hasło użytkownika zamienić "magicznie" na kilka ustalonych (rzadko zmienianych) haseł do różnych zasobów. W takim wypadku jednym z rozwiązań jest stworzenie servleta, który poda aplikacji w locie potrzebne hasła, albo jeszcze bezpieczniej - będzie pośrednikiem w przekazywaniu do aplikacji niezbędnych z tych zasobów danych. To pierwsze jest łatwe, lecz bez silnego szyfrowania komunikacji stosunkowo łatwe do złamania. To drugie trudne do złamania bo do kodu po stronie serwera cracker nie będzie miał dostępu, ale o wiele bardziej skomplikowane w wykonaniu i utrzymywaniu. Tak czy inaczej każde sensowne zabezpieczenie bazuje na aktywnym wykonywaniu (niedostępnego z zewnątrz) kodu po stronie serwera.

Hasla trzymasz w plikach ktore maja ustawione uprawnienia aby tylko ten i ten user i tylko ta i ta grupa mogly ten plik czytac. Aplikacja jest uruchamiana z prawami danego usera i moze czytac, wiec ma hasla. A opieke nad plikami itp zostawiasz systemowi oraz adminom.