# Passwort im Quellcode angeben?



## Manfred (16. Aug 2004)

Hi!

Eine simple Frage: Wenn ich eine Verbindung zu einer Datenbank herstelle, die mit Usernamen und Passwort gesichert ist, ist es dann kein Problem, dass im Prinzip jeder durch einen Decompiler diese Daten auslesen kann??


----------



## thE_29 (16. Aug 2004)

jop, kann er woll machen


----------



## Gast (14. Jul 2005)

Hi Leute,

gibt es die Möglichkeit Passwörter verschlüsselt z.B. in xmlDateien abzuspeichern (wie geht das) ?

bzw. kann man sich auch über JDBC anmelden ohne das Passwort eingeben zu müssen, sondern, dass man den aktuellen WindowsBenutzer nimmt sofern dieser die rechte dazu hat,
was muss man dann als User und als passwort eingeben, irgendwas mit $ oder so ?


Gruß
Schorsch


----------



## L-ectron-X (14. Jul 2005)

thE_29 hat gesagt.:
			
		

> jop, kann er woll machen


Nur mal so 'ne Frage am Rande: Wenn du keine Antwort hast, warum antwortest du dann? :?


----------



## DP (14. Jul 2005)

L-ectron-X hat gesagt.:
			
		

> thE_29 hat gesagt.:
> 
> 
> 
> ...



?! er hat doch geantwortet dass durch das dekompilieren das pw sichtbar wird und so an die daten kommt...

btt: sicher ist garnichts. auch die verschlüsselung nicht. denn die entschlüsselung wird dann auch irgendwo im code stehen.

also entweder das pw manuell eingeben lassen (z.b. mit einem login für die ganze session) oder z.b. die authorisierung vom os nutzen... was natürlich auch nicht 100% sicher ist...


----------



## abollm (15. Jul 2005)

DP hat gesagt.:
			
		

> L-ectron-X hat gesagt.:
> 
> 
> 
> ...



Kleine ergänzende Korrektur: _Ganz_ sicher ist gar nichts.

Passwörter sowohl _niemals_ im Quelltext oder in irgendeiner Form in der Datenbank speichern. Das Speichern der verschlüsselten Kombination von User/Passwort geschieht ohnehin der Datenbank. Die meisten Datenbanken verwenden für die Kombination von Usernamen und Passwort einen Hash, den man im Normalfall nicht knacken kann.

Wenn man zudem den Login über eine gesicherte (verschlüsselte) Verbindung herstellt, ist auch das Risiko des Auspionierens von Passwörtern über das Netzwerk minimiert.

Zum Thema Entschlüsselung im Code:

Bei Einsatz einer asymmetrischen Veschlüsselung (zwei Schlüssel bzw. ein Schlüsselpaar) kann man auch hier das Risiko einer Decodierung minimieren.


----------



## thE_29 (15. Jul 2005)

L-ectron-X hat gesagt.:
			
		

> thE_29 hat gesagt.:
> 
> 
> 
> ...




Was meinst du?? Meines war ne Antwort.. deines ne sinnlose Frage :bae:


hihi   :gaen:


----------



## stev.glasow (15. Jul 2005)

Naja, die Frage war ja ob es ein Problem ist dass jeder die Daten lesen kann, zumindest stehts so da. 
Seh in "jop, kann er woll machen" irgendwie keinen Zusammenhang zur Frage, deshalb wohl auch die Reaktion von L-ectron-X. Aber klärt das bitte per PN.
Zurück zum Thema.
[edit]
Was soll das mit dem Passwort verschlüsseln bringen? Der Client braucht das PW ja doch igendwann im Klartext und wie er das PW entschlüsselt steht ja auch im Code, den man ja decompilieren kann.
Ich würde erstmal über den DB Account einen Grossteil ausschließen und wenn das nicht reicht würde ich über einen Applicationserver gehen:
Der Applicationserver hat über JDBC Zugriff auf die Datenbank und liefert dem Client die entsprechenden Daten oder schreibt sie in die Datenbank - der Client bekommt nur Zugriff auf den Applicationserver und dient nur noch als Benutzerschnittstelle - für die Programmlogik sorgt dann der Applicationserver, auf dessen decompilierbaren Code niemand Zugriff hat.


----------



## DP (15. Jul 2005)

stevg hat gesagt.:
			
		

> Naja, die Frage war ja ob es ein Problem ist dass jeder die Daten lesen kann, zumindest stehts so da.
> Seh in "jop, kann er woll machen" irgendwie keinen Zusammenhang zur Frage, deshalb wohl auch die Reaktion von L-ectron-X. Aber klärt das bitte per PN.



hör auf zu singen 



			
				stevg hat gesagt.:
			
		

> Der Applicationserver hat über JDBC Zugriff auf die Datenbank und liefert dem Client die entsprechenden Daten oder schreibt sie in die Datenbank - der Client bekommt nur Zugriff auf den Applicationserver und dient nur noch als Benutzerschnittstelle - für die Programmlogik sorgt dann der Applicationserver, auf dessen decompilierbaren Code niemand Zugriff hat.



tjo, und wenn einer auf den app-server zugreifen kann, dann kommt er auch an das pw...


----------



## robertpic71 (15. Jul 2005)

@manfred:
man braucht meistens gar keinen decompiler, es reicht ein Hexeditor und ein wenig Sucharbeit

aus 


```
....
    // Connect to the local database
    Connection conn =
      DriverManager.getConnection ("jdbc:oracle:thin:@192.168.1.230:1521:SAT",
                                   "user", "pass");
...
```

wird im Hexeditor:


```
07 00 35 0c 00 36 00 37 01 00 28 6a 64 62 63 3a  ..5..6.7..(jdbc:
6f 72 61 63 6c 65 3a 74 68 69 6e 3a 40 31 39 32   oracle:thin:@192
2e 31 36 38 2e 31 2e 32 33 30 3a 31 35 32 31 3a  .168.1.230:1521:
53 41 54 01 00 04 75 73 65 72 01 00 04 70 61 73  SAT...user...pas
73 0c 00 38 00 39 07 00 3a 0c 00 3b 00 3c 01  00  s..8.9..:..;.<..
```

Wenn der "Angreifer" Zugriff auf das Object hat, gibt es wohl keine 100%ige Sicherheit. Aber den Benutzerkreis etwas "verkleineren", sprich das Passwort im Source bzw. den Properties verschlüsseln.

LG Rob


----------



## L-ectron-X (16. Jul 2005)

Ich glaube, das ist einer der Bereiche, in denen native Sprachen Java überlegen sind. Oder?


----------



## stev.glasow (17. Jul 2005)

L-ectron-X hat gesagt.:
			
		

> Ich glaube, das ist einer der Bereiche, in denen native Sprachen Java überlegen sind. Oder?


Die Zugangsdaten sind dort doch auch mit dem HEX-Editor sichbar.




			
				DP hat gesagt.:
			
		

> stevg hat gesagt.:
> 
> 
> 
> ...


Wie soll er da ran kommen?


----------

