JPA/ Webservice: Passwort Feld einer Klasse fürs Lesen "verschleiern"

[Gast2]

Hallo jGemeinde.

Ich bastel momentan einen Webservice. Die darunterliegende Datenbank enthält u.a. - wie oft üblich - auch eine User-Tabelle mit benutzerspezifischen Daten, also Username, Email, etc. und halt auch ein Passwort. Es soll möglich sein, User über den Webservice zu lesen als auch zu manipulieren, somit sähe die Klasse erstmal grob derart aus:

public class User{
private String name;
private String email;
private String password;

public String getName(){
return name;
}
public void setName(String name){
this.name = name;
}
public String getEmail(){
return email;
}
public void setEmail(String name){
this.email = email;
}
public String getPassword(){
return password;
}
public void setPassword(String password){
this.password = password;
}
}

Soweit so gut oder eben genau der Knackpunkt:
Dass das Passwort gesetzt werden können soll, ist ja ok, zb im Falle eines Anlegens eines neuen Users. Nur tu ich mich schwer mit der Tatsache, dass beim Abrufen von n Users halt alle Daten inklusive der Passwörter - die zwar verschlüsselt sind - aber dennoch verfügbar sein würden.

Mich würde interessieren, was so die best practices wären, derartige Felder "lese zu schützen". Irgendwelche Tips?

Das darunterliegende Framework zur Datenbankinteraktion ist EclipseLink, falls das von Belange sein sollte.

Danke vorab für Ideen und Anregungen.

 

[SlaterB]

welche bösen Stellen willst du denn ausschließen, den WebService an sich oder dessen Clients?
an den Client kann man ja nun wirklich nur Teil der Daten senden, Passwort manuell auf null setzen,
aufpassen dass bei Update zurückgeliefert nicht in der DB das Passwort gelöscht wird

innerhalb des Servers ist die Lösch-Gefahr noch höher, jedenfalls wenn ich an mein Hibernate denke mit von der Session automatisch nach Änderungen kontrollierte DB-Objekten,
da wäre es denkbar, in dafür geeigneten Bereichen nicht den User mit Passwort an sich zu benutzen, sondern andere Objekte, z.B. SimpleUser,

um die zu bekommen, wieder aus Hibernate-Sicht:
1. in Queries nur bestimmte Felder abfragen, Objekte halb-manuell zusammenbauen
"SELECT new SimpleUser(u.name, u.email) from User u",
solche Objekte werden dann auch nicht von der Session kontrolliert

2. ein separates Mapping auf die Tabelle, ohne das Passwortfeld, SimpleUser ist dann zu User gleichwertig, bis auf ein Feld weniger

---

edit:
der direkte Weg, die get-Methode zu entfernen oder statt public nur protected/ private zu machen,
ist auch nicht zu verachten, das automatische Mapping kann bei manchen dieser Schritte immer noch funktionieren, testen!

set-Methode kann bleiben, ist ja nicht gefährlich,
wenn das Passwort für Vergleiche benötigt wird, reicht evtl.
> public boolean isThisTheRightPasswort(String _otherPasswort);
ohne get

 

[Gast2]

Danke erstmal für die Antwort. Generell missfällt mir halt eine getPassword()-Methode an sich. Aber um auf die letzte Möglichkeit - des Entfernens/ private oder protected- Machen der get-Methode zu sprechen zu kommen: Nach meinem Verständnis war es doch so, dass via SOAP sowohl Getter als auch Setter existieren müssen, dass ein Feld sichtbar ist oder irre ich mich da?
Wenn das irgendwie möglich ist, wäre das ja durchaus ein Weg. Ansonsten müsste ich mir den Weg über die zweite Klasse durchdenken. Problem ist halt immer - wie Du schon sagst - die korrekte Persistenzabbildung.

 

[maki]

Passwörter selber herumzureichen ist doch längst out, hashcodes reichen doch.

 

[SlaterB]

> Nach meinem Verständnis war es doch so, dass via SOAP sowohl Getter als auch Setter existieren müssen, dass ein Feld sichtbar ist oder irre ich mich da?

ich beziehe mich mit getter/ nicht getter auf innerhalb des Servers/ Anbindung an DB

was bei SOAP/ WEbService passiert hast du doch viel eher unter Kontrolle, da würde ich das Bean nicht kaputtmachen wegen korrekter Übertragung, richtig,
dafür dann kontrollieren, was gesendet werden muss und kann,
beim Anlegen eines Users wird das Passwort, ob original, verschlüsselt oder verhasht übertragen, dagegen hast du ja sicher nix,
nur bei anderen Abfragen, die vielleicht nur die Usernamen anzeigen wollen, dann auch nur die Usernamen übertragen,
das Passwort im zu übertragenden Transferobjekt auf null setzen oder ähnliches

 

[Gast2]

Passwörter selber herumzureichen ist doch längst out, hashcodes reichen doch.

Gibt's da ein Beispiel für?
Ich muss allerdings dazusagen, dass ich ein bestehendes Projekt ergänze, wo auch Clients - leider Gottes - noch direkt auf die Datenbank zugreifen. Sprich Platz für revolutionäre Änderungen ist sehr klein...

 

[maki]

Gibt's da ein Beispiel für?
Ich muss allerdings dazusagen, dass ich ein bestehendes Projekt ergänze, wo auch Clients - leider Gottes - noch direkt auf die Datenbank zugreifen. Sprich Platz für revolutionäre Änderungen ist sehr klein...

Hab jetzt kein Beispiel zur Hand, Dr. Google sollte aber welche finden können.
Das Passwort steht aber nicht im Quelltext der Clients? Falls doch, kannst du dir den Aufwand gleich sparen....

 

[Gast2]

Das Passwort steht aber nicht im Quelltext der Clients?

Nein, um Gottes Willen. Es geht dabei auch nicht um die Absicherung des Webservice an sich, das steht nochmal auf einem anderen Blatt.

 

[Gast2]

Mir kommt gerade ein anderer Gedanke. Ausgehend von der Klasse aus dem Ausgangs-Thread und anzunehmen, dass alle Variablen auf Datenbankfelder gemappt sind, für den Passwort-Part:

public class User{
...
@Column(name = "password")
private String password;

public String getPassword(){
return password;
}
public void setPassword(String password){
this.password = password;
}
...
}

...geändert in...

public class User{
...
@Column(name = "password")
private String realPassword;
private String password;

protected String getRealPassword(){
return realPassword;
}
protected void setRealPassword(String realPassword){
this.realPassword = realPassword;
}

public String getPassword(){
return null;
}
public void setPassword(String password){
setRealPassword(password);
}
...
}

Das Passwortfeld wäre generell verfügbar via SOAP, liefert aber nichts, sondern kann nur setzen. Gibt es Bedenken in Richtung JPA?

 

[SlaterB]

was ist denn dabei der Unterschied zu

public class User{
...
@Column(name = "password")
private String password;

protected String getPassword(){
   return password;
}
public void setPassword(String password){
   this.password = password;
}
...
}

?

 

[Gast2]

Der Unterschied ist, dass realPassword das tatsächlich gemappte Datenbankfeld ist, aber nicht via SOAP veräusserlicht wird. Das wird password, was eben via getPassword null zurückliefert, seine set-Methode setzt dann das gemappte realPassword.