I have created a bot using power virtual agent which will assist user in changing their password. User need to pass their current and new password for this. And then I am calling power automate flow and then making use of API https://graph.microsoft.com/v1.0/me/changePassword to change password by passing body as
{
"currentPassword": "Test123456",
"newPassword": "Test12345678"
}
I see a security issue here wherein execution history gets stored in power automate and admin can see users passwords using it.
Any idea on how to overcome this?
You can enable secure input and secure output in the settings an Power Automate actions.
After enabling it will show up like below in the flow history.
Related
If you have an ASP.NET MVC 5 site configured without email confirmation, how can a password reset be performed by an administrator?
I can write a console app which resets the password in the database, but that seems inefficient. Also, the old aspnet_Membership_ResetPassword sproc has no counterpart in the new identity system.
I'm not sure I understand what you're trying to achieve. You still have to get the password to the user somehow, so will you be emailing them a generated password instead of the standard "follow a link in a email to a page that lets you pick a new password" approach?
Also, are you talking about specifically resetting one user's password or resetting all user passwords. If the latter, then a console app is the way to go. If the former, you can simply add a view to some backend that's only accessible to admins that let's them perform this function for a specific user.
As far as generating some random password goes, you're on your own there, but a simple web search should turn up plenty of methods to choose from.
Word to the wise, though, the email confirmation approach is standard for a reason. It provides a relatively secure way to allow a user to regain access to their account when they can't remember their password. It's most important feature, though, is that it forces the user to actually change their password, whereas with a provided password, random or not, users will actually use that password, rather than take the time to manually change it after logging in - especially with password managers these days. That means if you sent that password via email, or wrote it on a sticky or whatever, you now have a huge gaping security hole.
I am not sure if this was already asked/ discussed before.
In my Jenkins, I have setup LDAP authentication and that password is required in one of my jobs to remotely login to a different server using that password and execute some tasks there
Assume the remote task is executed via sshexec in ant task which requires username password. I dont want the user to enter the password again in the form of a build paramater, is there a way to get the password used for Jenkins authentication inside the build job ???
[I]s there a way to get the password used for Jenkins authentication inside the build job?
Not as such. Jenkins does not retain the password after you log in, it simply passes it to the LDAP server long enough to verify that you should be authenticated.
So what you need is to define Credentials persisted in Jenkins that can be used during a build. You can use the Credentials Binding plugin to set up a fixed username/password which the job will have access to.
If your requirement is for the credentials to not be available for any build of the job, but instead that a user manually initiating the build should have to supply them (meaning that scheduled or otherwise triggered builds are impossible), I think this is also supported as of version 1.1. Define a parameter of credentials type for the job, to be used via variable expansion in the binding. Then have the user define these credentials in their user configuration page (/me/configure). Then when selecting Build with Parameters they should see their own personal credentials and be able to select them. The user needs the Credentials/UseOwn permission on the job.
Another option for the future would be a subtype of username/password credentials which does not store the password at all (maybe just a “salted” hash, using jBCrypt), and somehow prompts for you to enter the password before the credentials are considered valid, probably expiring after a few minutes. This mode has not been implemented but would be useful for sites with stricter security requirements.
(Regular credentials are stored encrypted, but the default secure storage mechanism keeps the master encryption key in $JENKINS_HOME—so secure so long as you do not allow shell access to your server to anyone who is not already a Jenkins administrator, and of course so long as you configure the master computer to have zero executors so people cannot run builds on it, only on slaves. Another RFE would be an alternate storage mechanism that allows the master key to be injected by some other means.)
The best possible way to do is to allow permission to jenkins user in the remote server.
We're using Jenkins server (v. 1.571) with the following authorization configuration:
Security Realm: Unix user/group database.
Authorization: Matrix-based security
up until now, each member of our team used its private credentials to login and perform operations on this server.
We want to enable bot scripts to login to the server with "global" credentials and perform some of these operations, without changing the current credentials of the users (and hopefully, don't touch the current authorization guidelines).
How can this be achieved?
thanks!
You can check Mask Passwords Plugin. It provides you the option to define user and password in Manage Hudson > Configure System section. To add to it, as the name suggests, the password will be masked in the console output. Even in the Configure section where you create user and password, the password will remain in masked state.
I am building a non-interactive application that works with the Valence API, and I am having a hard time wrapping my head around how the authentication (specifically, the process of obtaining the User Id and Key) is supposed to work. My D2L administrator has provided me with my App Id and Key and I have been able to use them and the getting started sample to obtain my User Id and Key, but I cannot figure out if it is possible to get the latter in a purely non-interactive fashion.
I would like to know if this is possible at all, or if the interactive process of obtaining the API credentials is required.
Currently, the interactive process is required in order to obtain a User ID/Key. It should be possible to fake this by simulating the posting of the login form, if you are really desperate, but obviously this is an unsupported arrangement and would be very fragile and prone to breakage if anything changed in the login form.
I have a requirement to implement user privilege elevation in an MVC3 web app, for both Forms and Windows authentication, but this question is critical for Windows auth. This is for a higher privileged user to give assistance to a lower privileged user, e.g. when a clerical user is performing a task and requires an admin user to do a task before the clerical user can continue, the admin user should be able to elevate the same session to their privilege level, perform the admin task, and restore the lower privilege to the session. I don't see a way here without the clerical user logging off and the admin user logging on, given that we want to achieve this on the desktop of the clerical user alone. Maybe user switching is tidier than a whole new session, but I would very much like a "run as" equivalent for Windows authenticated web apps.
Is this even possible, and if so, how can I achieve this? I have no idea where to even begin looking.
Allow the "power user" to temporary set a specific role for other users and for example setting also an expiration of the role with a DateTime.
You could put an anchor somewhere on your site:
#Html.ActionLink("elevate to admin", "SwitchToAdmin", "Home")
and then have a controller action which will allow for inputting the administrator credentials:
public ActionResult SwitchToAdmin()
{
// TODO: Adjust the role name that your administrators will have
if (!User.IsInRole(#"DOMAIN\Administrators"))
{
// The user is not currently an admin => popup a Logon box
// so that the administrator could authenticate himself
return new HttpUnauthorizedResult();
}
else
{
// After inputting the correct username and password for the
// admin, we can now redirect to the home action and start performing
// the admin tasks
return RedirectToAction("index", "home");
}
}
The revert process will be the inverse. You could have a link which will call a controller action that will throw 401 if the user is an admin allowing for the normal user to enter his username and password.
In order to use Windows authentication to do this I think you will need:
The run as command
A shortcut on the user's desktop to start the other logon
Either a batch script to prompt for the user's logon information or a separate desktop program to gather the information (the shortcut points to whichever of these you choose)
once the information for the run as commandline is ready you could either start a browser or perhaps a custom program with an embedded browser.
An advantage of the program with embedded browser approach is that it can have extra security precautions such as forcibly closing itself after a timeout.
Anyway that's one possible solution. You might also try to come up with a less complicated way to solve the business need. Perhaps a remote desktop session for the admin?
The equivalent of the run as command is using user impersonation. That is running the commands that requires higher privileges as another user.
It should work as follows:
1) User try to access privileged resources. The webapp detect this either because it has a kind of table of all task reuiring higher privileges, or by intercepting the security exception it gets trying to perform the operation.
2)When this is detected you throw a "RequiresPrivilegesElevationException"(an exception you have to define). This exception i catched by the controller, that now knows it must prompt the user for higher privileges
3) the controller prompt the user for the admin (or higher privileges user password)
4) when the user send the credentilas (via https) credentials are used to create an impersonation context, and all operations are done within this impersonation context.
The drawback of thos approach is that the credentials and the privilege elevetion last for just one trip to the server...for any other request the user is forced to re insert the credentials. THERE IS NO SAFE WAY TO AVOID THIS due to security browser limitations