Is there any API to get the currently logged in user's name and password in Windows?
Thank you in advance.
Password: No, this is not retained for security reasons - it's used, then discarded. You could retrieve the encrypted password for this user from the registry, given sufficient privileges, then decrypt it using something like rainbow tables, but that's extremely resource intensive and time consuming using current methods. Much better to prompt the user.
Alternatively, if you want to implement some sort of 'single signon' system as Novell does, you should do it via either a GINA (pre-Vista) or a Credential Provider (Vista), which will result in your code being given the username and password at login, the only time at which the password is available.
For username, getting the current username (the one who is running your code) is easy: the GetUserName function in AdvApi32.dll does exactly this for you.
If you're running as a service, you need to remember there is no one "logged in user": there are several at any time, such as LocalSystem, NetworkService, SYSTEM and other accounts, in addition to any actual people. This article provides some sample code and documentation for doing that.
For the many commenters who believe it is not possible to reveal the password of the currently logged-in user, see Dump cleartext passwords of logged in user(s) which shows how to use mimikatz to do just that:
mimikatz # privilege::debug
Demande d'ACTIVATION du privilège : SeDebugPrivilege : OK
mimikatz # sekurlsa::logonPasswords full
...
Utilisateur principal : user
Domaine d'authentification : domain
kerberos :
* Utilisateur : user
* Domaine : domain
* Mot de passe : pass
I'd consider it a huge security flaw if that were possible!
You can't get the password of a user since its encrypted (not to mention that its a standard practice not to store passwords in plaintext).
For getting the username, you can use GetUserName or NPGetUser
Note sure how it is done, but "Network Password Recovery" tool from http://www.nirsoft.net/utils/network_password_recovery.html seems to get the password from some cache.
GetUserName will get you the name, but the password you can't get. It's not even something Windows stores, AFAIK - only a hash of your password.
Depending on what you're trying to achieve (you can tell us a bit more..) it's possible to impersonate a logged on user and do stuff on his/her behalf.
Full details of Authentication in the Windows API can be found on MSDN:
http://msdn.microsoft.com/en-us/library/aa374735(VS.85).aspx
I don't know about the windows login password... but you can definitely pull plaintext passwords from the Credentials Manager. For example here is a program to pull the password for TFS. In most cases, this is the same as the Windows Login.
namespace ShowPassword
{
using Microsoft.TeamFoundation.Client;
using System;
using System.Net;
class Program
{
static void Main(string[] args)
{
var tpc = new TfsTeamProjectCollection(new Uri("http://mycompany.com/tfs"));
var nc = tpc.Credentials as NetworkCredential;
Console.WriteLine("the password is " + nc.Password);
}
}
}
I compiled this as "console" app under vs 2015 with Nuget package TeamFoundation ExtendedClient.
You can get the user name with GetUserName(), but you cannot get the password; this would violate security for dummies 101.
re "Network Password Recovery" tool
Windows (upto XP) stores a copy of the passwd with a simpler easy to break encryption - for connecting to older style lanmanager network shares.
The tools generaly try all possible passwords against this, using rainbow tables (precaluted encrypted versions of dictionary words) speeds this up.
In XPsp2/3 Vista this feature is removed. The new encryption is much harder to crack and needs many hours to try all possible values, there are online services that will run it on large number of machines to give you a quick answer for a price.
To answer the original poster - you do not generally store the password and compare it with what the user typd in. You encrypt (actually hash) the entered password and store that. To check a password you perform the same encryption on whatever the user enetered and compare that. It is generally impossible to go from the encrypted form back to the real password.
EDIT I suspect you are asking the wrong question here - why do you want the password, what are you trying to verify and when?
Related
I would need a readout of joomlas user password in plain style to give special users the ability to send a mail in a custom module with login details like:
https://mydomain/login?user=testuser
password = testuserpassword
For that reason I need the plain passowrd out of the DB. Is there a way to show/read out password from joomla-db in plain style?
Thx in advanced!
Joomla saves the passwords in the database using a one way encryption mechanism, which means that you cannot know what the password is.
I am sure what you're doing can be done in a different method - if you want to login users automatically once they click on a link then you can have a different authentication plugin that will use a random, unique, one-time-use, and time-sensitive hash that will be associated with a Joomla user account.
You need to create a plugin with function after joomla user save
you need to store password in another table with user id and then you can use with sql query to get password.
This is a bad idea for the following reasons:
email is sent in plain text
email often is stored on several systems along the way to your mailbox
email often is stored on your computer in plain text or other unencrypted format
many copies may exist in many places, even after "deletion"
even encrypted email can be broken in to, given enough computing time
your account's security may have been compromised even before you read your email (changing the password will not help in this case)
However, you definitely can email the user their password upon initial registration by going to Global Configuration > Users and setting Send Password to "Yes" (default setting in Joomla 3.x).
If you are looking for a way to send this password after the registration event, as others have mentioned, you are out of luck. What Joomla! provides is a secure password reset functionality to reset a password to something the user can remember. This will be the best approach for you, as well.
Resources: Sending Passwords in Email, Stop Joomla Sending Passwords in Emails
I'm developping an application with Spring MVC, and I want to add the security aspect to my authentication.
In my application I have the login and the password are registred in the database and any one who has access to it can see the login and the password clearly.
I want to have data encrypted in the database so that I will be sure that no one can use or divulgue them .
I've searched in the net but I found that there are some algorithms which may encrypt data such as md5 ,but the problem it's irreversible.
Could some body help me ?
I agree with Danny H, but wanted to address the other half of your question too: protecting the login (usually an email address). Most people ignore the need to protect it, but for website that want to maintain secrecy of their customers (not just Ashley Madison but also medical websites), then you'd want to add a layer of protection for the other data.
First, a reference on protecting the password: Secure Salted Password Hashing. Use either bcrypt, scrypt, PBKDF2, or argon2.
Now what about protecting the login? You can actually do a similar thing for protecting it, but you will need a fixed salt for it (for passwords, the salt must not be fixed!). Let's assume bcrypt is used for my example below.
Consider how the user would login: User enters his login id and password. System applies bcrypt to login id with fixed salt to look up user in database. From that, system gets the user's password salt, and system computes bcrypt on user provided password with salt to see if it matches hashed password in database. If so, user is granted access. Therefore, system granted access without storing the user’s login id in plaintext form in the database.
What about user forgetting password? No problem if the login id is the email address: the user enters login (email address) on forgot password page, system applies bcrypt with fixed salt on user entered email address to see if the user exists in database, and assuming yes, then emails the user a secret link for password reset. Within the database, we have to associate that secret link to this user to make sure he only resets his own password (not somebody else’s!).
What if the database is exposed? Anybody could determine if a specific user is in the database by computing bcrypt on that user’s email address and looking for a match in the database, but nobody is going to be able to reverse the entire collection of email addresses, which is a big improvement over the present situation.
I discussed this idea in a blog of mine more than 2 months ago, see: https://littlemaninmyhead.wordpress.com/2015/09/08/a-retrospective-on-ashely-madison-and-the-value-of-threat-modeling/
Why is it a problem that the encryption of passwords is irreversible?
When the user creates an account, salt and hash their password before saving. I prefer using bcrypt.
When the user logs in, you can use bcrypt's checkpw to compare the users credentials to the hashed ones saved in the db. Having them irreversible(undecryptable) ensures that if someone gains access to your db, they don't get all of your users passwords as well
I haven't used BCrypt with java before but I just glanced over this tutorial and it seemed like it may be a good starting place for you
Edit : Just realized he was using jBCrypt but the differences in the two should be very minimal
Edit2 : Here is a pretty good article on cracking passwords that are found in the database and a reason I recommend bcrypt and why you should use one-way encryption
MD5 is a hash function which is not reversible - it is not an encryption function. Hashes give the same output for a given input every time, that's why they work. Hashing would work in the scenario you described because the users who could see the hashes wouldn't know the original password - that said, it still sounds like a bad idea.
Ideally you would hash the passwords then encrypt the hash and other users wouldn't be able to see these values encrypted or not. That would be my suggestion, but if you choose only to encrypt the passwords RSA encryption would work just fine.
I have a PowerShell script which does the following on Windows 7 computers:
Get a random password from a secure server-side application
reset the password of a specific local user account using this password value
As a next step, I want to periodically check if the password saved on the server is still valid. For now, I am using ValidateCredentials from System.DirectoryServices.AccountManagement.PrincipalContext (see Powershell To Check Local Admin Credentials) but it involves to unencrypt the password and send it back to the computer just for this purpose.
Do you see any better way to check if password is still valid avoiding to use clear text password ? Is it possible to compare some hash, or anything else ?
Regards.
You can check the attribute PasswordAge and do a little math to see if the last time the password was changed was the time you set the password.
which would be the best way to encrypt the connection string for SQL SErver CE (Local Database) or the password-connection for a windows phone app? because if you have it in plain text, example:
"Data Source='isostore:/database.sdf';Password='mypassword';"
is vulnerable if anyone decompiles your app.
But if I have the encrypted password in a file (stored in isolatedstorage) may also be vulnerable if someone decompiles the app because he can see the code to decrypt.
Another way would be encrypt with a key that is not stored. The problem is that I dont want that the user enter each time the pin or password to access.....and if he forgets his pin or key can not access your private data.
The data contained in the database are of basic type (contacts, tasks, ...). Data are not high risk or condifential...
Any idea?
This recent question contains lots of helpful suggestions - How can I securely embed a static string (key) in C#?
However, for accessing a local database, then I'm not sure you need this security at all - I think the WP7 sandbox will keep your database safe from other apps.
There is always a security risk if you have got sensitive data stored locally on the phone, there are a few ways to mitigate this.
i) Use the built in ProtectedData.Protect which is built into the phone, with no additional entropy data - this would encrypt the data, and the user would not need to enter anything
ii) again use ProtectedData.Protect but get the user to enter a password and use that as the additional entropy value, but as you say if they forget the password you cannot get the data back
iii) Store the data in a cloud based service and get the app to retrieve the details as required.
Hope this helps.
The only way to not have a password on the phone (even in an obfuscated form) is to retrieve this from a remote/web server when first needed and then store on the device use the ProtectedData class.
Currently I am developing an application with 3 roles: 1 for customers, 1 for the company employees and another one for a Super Admin.
Is it a good practice to allow Super Admin users to see/edit the users' passwords through the UI? Or should it only be modified directly through the DB?
UPDATE: I am using asp.net membership provider and MySQL. Therefore, there is a table in the DB called my_aspnet_membership which stores two fields: Password and PasswordKey. The field PasswordKey seems to be the encrypted password. However, the Password field is stored in plain text. So, can anyone tell me why this is designed in this way if it is not a good practice? Thank you all for your responses!
UPDATE: For those who asked if it really stores the password in two different fields:
Your password should not be stored un encrypted inside your database and as such, shouldn't be visible to users of the UI nor the database.
As for whether it should be modifyable, sure.
In this case the password should be re-generated through user or administrator request. Again, this should be encrypted in the database. My preference would be to auto generate the new password for the user rather than have an administrator type it themselves.
Given this, the only way to change the password directly in the database would be to encrypt it first before insertion. It's quicker to do this through an UI that deals with the encrypting.
UPDATE
In answer to your update, you should specify in your web.config that the password format be hashed:
<providers>
<add [...]
passwordFormat="Hashed"
/>
</providers>
as outlined here:
http://msdn.microsoft.com/en-us/library/ff648345.aspx
There is never a reason to allow someone to see a password they do not own, under any circumstance.
Update for the OP Update: Of course I have no way to know why your DB was designed like this. Thinking optimistically, it contains the plain password so that if a user forgets their password it can be mailed to them -- a bad excuse, but an unfortunately common one. A better alternative is to have the system mail them a freshly generated temporary password -- one which works only to allow setting of a permanent password (and does not destroy the current password until the change occurs).
No user should be allowed to see the Plaintext password of any other user whatsoever. The password must be encrypted atleast if not hashed even in the database.
You MAY allow the super admin to change any user's password, but allowing him to see it in plaintext is taboo.
EDIT: Are you absolutely certain the password field stores the password in plaintext, while there exists another passwordkey field? Because, it sounds similar to a 'salt' mechanism to me. Where, the password is first encrypted with one key, and then re-encrypted with the passwordkey field.
EDIT 2: I am now almost absolutely certain that your database is using a salted password. Salted passwords are often used to increase the security level of the database. For more information on salt, check this.
You should always save passwords encrypted. Therefore you don't have any possibility to show the superadmin the password of another user.
You should never ever store password as is in any database. Always use a hash function to save the password.
You should save all passwords encrypted in DB.. Not in plaintext!!