I would like to compare a String to the password of the currently authenticated user (encrypted keys comparison). It seems like retrieving password from the ticket cache but how can I do that?
Thank you
It is not possible to retrieve the password from information that are available on the client or anywhere in a kerberos system. According to the kerberos article in wikipedia (which holds similar information to what I read at other sources) the user entered password is hashed with a one-way function into something that serves as the secret from this point on. The secret is available at the key distribution center (KDC) and the ticket granting ticket (TGT) is symmetrically encrypted with this secret. To receive and use the TGT, a client has to provide the secret to decrypt the package - which is done by asking for the password from the user. After doing so, the TGT is decrypted and is saved in the ticket cache.
The TGT itself has parts encrypted with a secret only the kdc knows, it does not hold the password of the user. As, for example, this article from 2000 explains, the password is not stored in the ticket cache either - just parts from the TGT. From my understanding it is not possible, to check the user password using the ticket cache.
You might want to write your own CallbackHandler to somehow reuse or provide the credentials programmatically, but from my understanding this might lead to security problems.
You might want to think about solving your problem with a total different approach, but there is to little information to suggest any other solution.
I don't know if that's intended to be possible. That hash may be salted with a key known only to the server. What I'd try instead is to just authenticate using the user's id and the given String. If the server accepts the authentication request, the password was valid.
Related
I have a program where the username and password is hard coded. So I want to pass that Executable JAR file to colleagues working in the same network. I want to secure the Password and don't want to reveal it to anyone. Is there a way where I can pass on the JAR File and keep my password secure without anybody coming to know about the password.
Maybe if there is a way of storing some password in a file and keeping it on a server and every time, the JAR file tries to run, it picks up the pass from the remote file?
Your headline and the content of your question are somehow contradicting. A hardcoded password ain't secure in the very first place.
I would recommend a different design: create some kind of service that allows access without a password; for example based on the network address of the client. That service would then be the only piece that really needs to know this password. And come the day that have to change something (like the password, or the actual software you are using) ... there will be only one thing you need to change.
Meaning: configure your JAR to trigger some RESTful service for example ... which in turn internally calls whatever application needs that username/password.
You could use a salted hash (hashing a random number + the password). It would ask them for a password and would hash the password and salt and compare it to the stored one. This is very weak security but is at least better than comparing it to a hardcoded password.
The hash function should be cryptographically secure, like SHA256. If you're not familiar with cryptographic hashes, it takes data of any size and mangles it down to a small fixed size fingerprint (MD5 is 128 bits, SHA1 is 160 bits, SHA256 is 256 bits, etc)
Here are examples of md5:
md5("abc"): 900150983cd24fb0d6963f7d28e17f72
md5("not secure"): 116e54e126621ed4070b2f30ebc07fec
So instead of storing the password "not secure" in your file, store the hash "116e54e126621ed4070b2f30ebc07fec" instead.
I saw many services, mainly map services like GMaps or MapQuest, that requires users registers previously to obtain an appKey. Later, on each request the user must attach the appKey like http://server/service?appKey=sdf7dfj34.
I understand this kind of appKeys are insecure and are mainly usefull to know the useage of your service. Anyone can see your appKey and make use on its own app.
I saw other services that, on registration proces, requires you put the domain where you will execute your code. This way they can check if the domain from which the request is made corresponds to the appKey generated for that domain.
My questions are:
Is this kind of control secure?
Can I ensure the user is really the one who register.
If the domain-appKey options is possible, how can implement it? (I'm using Java-Spring).
I must clarify my intention is users can requests data via appKey using JavaScript+AJAX.
Thanks.
Can't you just include the domain in the appKey? E.g. part of the appKey is hash of the domain (for simplest key you can use MD5 and base64 to encode hash bytes).
Then to validate domain you hash the request's domain and compare it with the appKey.
To clarify:
User wants to obtain an appKey for domain "user.domain.com".
You hash the "user.domain.com" to SOME_DOMAIN_HASH_TOKEN.
The appKey would be SOME_GUID + SOME_DOMAIN_HASH_TOKEN (+ may be something else)
User sends the appKey to your server from some domain.
You hash the domain from request and compare with hash from the appKey.
If both are SOME_DOMAIN_HASH_TOKEN the domain is valid.
First time doing a secure login from a mobile app to a server (built in java). I want to understand if I got this right.
Login in for the first time:
1. On the mobile device hardcode a security phrase (ex: "superSecurePhrase##!!".
2. Take in a username and password.
3. Use base64 to encode username+phrase and password+phrase.
4. Using https send this information to my server.
5. On the server decode using base64 with the matching phrase hardcoded on the device.
6. Hash password and save to DB, also hash username and save to DB.
7. Use AES algorithm to create a session token
8. Send session token to device.
9. Save session token to DB, and when user requests something, make sure they match.
To verify credentials it is pretty much the same process except username and password aren't saved, but instead queried for the DB and checked for a match?
Is this the general pattern used for this kind of thing?
Potential vulnerabilities:
1. Physical access to the device to retrieve the hard coded base64 phrase?
2. SSL Sniffing and acquiring the token?
Thank you for your help.
If I were on your place I would hash the password with SHA-1/SHA-2 on the device when registering. This way I will be sending only the hash. If the request is intercepted by a man in the middle, even if they decode the Base64 encoded string, they will have only the hash. As an end use I will be terrified if someone has my raw password, because I use it on other places (I know it is a bad practice). You can still Base64 encode the hash with the salt.
You can use your "superSecurePhrase##!!" to salt your password string during the SHA-1/2 encoding, or have a separate salt for this.
The token should be random on every generation (it stays the same until it expires), I would use something like the org.apache.commons.lang.RandomStringUtils, assuming you are using Java on the backend.
On the app side I would store the token in the shared preferences, if the device isn't rooted, it isn't accessible by other apps. If it is, and the user allowed root access to the app, you can't do anything about it. Storing in a databes is also OK, if you are already using a database in the app.
So, to sum it up, the biggest difference is that I would prefer to create the password hash on the device and send only the username and the hash over SSL.
In my application, users create data then use their secret key to calculate a hash. The data with the appended hash are sent to the server.
The server recalculates the hash using the private key it has listed for the user.
Now, on the server's side, I obviously can't store the secret key in plain-text. However, I also can't do a one way store using Hmac, because then, when I recalculate the hash on the data, it will give a different response.
What is the best way to store user's secret password on the server side?
The best way is what you are doing now. I mean the password is never stored either as plain text nor in encrypted reversable form. I did not exactly understand your problem but if you want to make the system truly secure find solution for your problem without using user's password in plain form.
But if you indeed need this I'd recommend you at least to store passwords in DB encrypted. The encryption password should be also hidden somehow to make potential hacker's work harder. But note: once you do it the system becomes breakable and all depends only on the hacker's professional skills and motivation.
Does anyone know how to hide the password contents in the source code of a j2me program? i.e. so people cannot see "DBT" as password who read the source code.
public void validateUser(String user, String Password) {
if (user.equals("N0203251") && Password.equals("DBT")) {
switchDisplayable(null, getContinue());
}
}
As other have said. Store the hash, though you still need to use a strong password or an automated guesser will find the one you're using.
But, be warned:
If your attacker has access to the source code he/she/it can alter the stored password hash or just remove the password check.
So this method is of little use unless you can verify the integrity of the code being run, which is hard.
When it comes down to it, you've written a back door into the program. That's a Bad Thing - don't do it.
Like others have said, you can do better by using a hash, but a couple critical things are left out. When someone guesses the password, they'll know the password for every installed copy of your software. Since the password is hard coded, nobody will be able to change it or revoke it, so you'll have inserted a back door in the program that nobody can eliminate. And if you rely on that password ofr any communication with other resources, you can't ever change it - at least, not without significant additional work.
What you should really do is place the password in an external location, such as a hardware security module, or password file, or database table. Then, implement a full password change and rotation mechanism - honestly, this should be pretty much the same mechanism you use across all your passwords.
You could store the hash (MD5 / SHA1) of the password instead and compare this with the hash of the supplied passwords.
Make sure you calculate the hash externally to avoid having the original password mentioned anywhere in the executable.
Use a function that hashes the password - keep the hash of a password in the source, not the password itself.
A quote from that page:
A related application is password
verification. Passwords are usually
not stored in cleartext, for obvious
reasons, but instead in digest form.
To authenticate a user, the password
presented by the user is hashed and
compared with the stored hash. This is
sometimes referred to as one-way
encryption.
If you are storing the application on the user's mobile device, the best you can do is try to obscure the password. I would recommend doing some sort of hashing algorithm (maybe SHA1) or a key derivation algorithm like PBKDF2 and storing the result rather than comparing against the plaintext password.
Storing the hash instead the password buys you absolutely nothing. Since it is now the hash being used to authenticate instead of the password, reading the source code (or reversing the object code) will reveal the hash and allow the attacker to authenticate.
The answer to these questions is always the same. You can't achieve any measurable security if you use hard-coded client-side secrets no matter what you do. The best you can do is obfuscate enough until you get a warm fuzzy feeling that it is good enough.