Best Practice Password ablegen

sebastianb

Erfahrenes Mitglied
Hallo Zusammen,

ich habe gerade ein kleines Problemchen auf das mir bisher keiner so richtig eine Antwort geben konnte.

Ich hab ein kleines Jira-Plugin programmiert, welches mir bestimmte Daten mit SalesForce abgleicht. Hierzu benutze ich eine Webservice(SOAP)-Schnittstelle, die auch eine Authentifizierung verlangt. Bisher speicher ich die hierzu nötigen Daten im Klartext in der Datenbank, was mir persönlich etwas im Magen schmerzt. Das Problem ist nun, wie ich solch ein Szenario sicher machen kann, weil irgendwie erscheint mir das Ganze als ein Henne-Ei-Problem: Verschlüssele ich die Daten in der Datenbank, wo tu ich dann den Schlüssle hin?

Gruß

Sebastian
 
Passworte verschlüsselt man nicht, die hash't man. MD5 oder noch besser SHA + salzen (kein Scherz).

Hashes kann man nicht mehr zurück in den Klartext verwandeln. Aber man kann folgendes tun: Leg den Hash in der DB ab. Beim Login wird das eingegebene Passwort ebenfalls gehash't und dann die beiden Hashes verglichen. Standard-Aufgabe :)
 
Hallo,

eine Möglichkeit ist in der Datenbank nur Hashes der Passwörter (SHA-1 besser SHA-256) (Hash mit einem Salt berechnen, das Salt kann man auch an dem entsprechenden Datensensatz der den Hash-enthält in der Datenbank oder extern ablegen- der Salt sollte dabei eine Zufallszahl sein).

@Saftmeister wird sind uns einig ;-)

Gruß Tom
 
Das ist alles soweit korrekt aber ein Hash bringt mir in diesem Fall nichts, da ich dann ja nicht mehr auf das eigentliche Passwort schließen kann und genau dieses brauch ich ja, um das Plugin bei Salesforce zu authentifizieren.

Ablauf:

In Jira wird beispielsweise ein neuer Issue angelegt. Hierbei wird ein Event geworfen, der mein Plugin antriggert. Weiterhin loggt sich das Plugin bei Salesforce ein und synchronisiert die jeweiligen Daten.

Wäre das Salesforce-Passwort nun gehasht, wäre eine Authentifizierung bei Salesforce nicht möglich. Ich hoffe ich versteht, was ich meine ;)

Gruß Sebastian
 
Zuletzt bearbeitet:
Hi Thomas,

ich verwende die partner.wsdl Quickstart

Der Login sieht hier wie folgt aus:

Java:
public PartnerConnection login(String username, String password)
	{
		try
		{
			ConnectorConfig config = new ConnectorConfig();
			config.setUsername(username);
			config.setPassword(password);
			config.setAuthEndpoint("https://login.salesforce.com/services/Soap/u/24.0");
			config.setPrettyPrintXml(true);
			return new PartnerConnection(config);

		}
		catch (Exception ce)
		{
			ce.printStackTrace();
		}
                return null;
	}

Gruß Sebastian
 
Hallo,

Wäre es eine Option für die das REST-Interface mit OAuth zu verwenden?
http://www.salesforce.com/us/develop...inName=webhelp

Dort gibt es auch die Möglichkeit als grant_type "authorization_code" zu verwenden.
Dann kannst du dich mit:
Code:
...
private string clientID = “YOUR CONSUMER KEY";
private string clientSecret = “YOUR CONSUMER SECRET";
...
auch ohne Benutzername und Passwort authentifizieren... nur mal so als Idee :)

Code:
...
post.addParameter("grant_type","authorization_code");
/** For session ID instead of OAuth 2.0, use "grant_type", "password" **/
...


Siehe auch:
http://danlb.blogspot.de/2010/10/salesforcecom-rest-api.html



Gruß Tom
 
Ja zuerst habe ich auch die Rest-Schnittstelle mit oAuth 2.0 und "authorization_code" verwendet aber das Arbeiten auf "richtigen" Objekten fand ich dann doch angenehmer ;)

Es kann natürlich auch sein, dass ich das Prinzip von oAuth 2.0 nicht richtig verstanden habe (Ist auch sehr verwirrend) aber so wie ich das sehe, delegiert oAuth (Unter Angabe vom ConsumerKey/Secret) die Authentifizierung zu Salesforce, die mich dann wieder nach erfolgreicher Authentifizierung zurück an meine Callback-Adresse leiten. Das Problem ist also, dass ich bei der Verwendung von "authorization_code" eine zusätzliche User-Interaktion habe. Verwende ich "grant_type=password", habe ich das gleiche Problem wie bei SOAP: Wohin mit dem Passwort.

Wie macht es an dieser Stelle zB der Firefox? Der speichert ja auch alle Passwörter verschlüsselt auf der Platte ab und kann diese nur mit dem Masterpasswort wieder entschlüsseln. Der muss das Masterpasswort ja auch irgendwo ablegen?

Gruß Sebastian
 
Zurück