I have several windows applications that can be access through an SQL account. I need to validate the user password against Local Security Policy of the Server without modfiying the password itself.
What I require is an SQL statement that return a boolean value whether or not the password is according to the server policy or not.
Is it something possible?
Based on the extra information in your comment, it seems that you want to validate existing SQL login passwords against the Windows password policy, but without making any changes to the logins.
This is probably not possible because there is no way to retrieve a SQL login password, so there is no way to validate them yourself programmatically. However, according to the documentation, the check is on by default, so it's possible that all your passwords are already compliant with the OS security policy, unless you've deliberately set this off and then on for some logins.
If you need to ensure that all login passwords comply with the policy, the best way to make sure is to set the check on for all logins (if it isn't already) and force a password change. Even better, stop using SQL logins and use Windows logins instead, although I know that isn't possible in every situation.
Related
I'm using Oracle Rest Data Services (ORDS) to build APIs.
The client requires basic authentication (username and password). This does not seem to be supported by OAUTH2.
Is there another way I can protect the APIs by means of just a username and password?
EDIT:
We are using IIS10 - is it possible to setup basic authentication from an IIS perspective?
Yes you can, but we don't recommend it.
You can create an ORDS user (use the user command), and assign a password and one or more roles.
You can fall back to database user/password auth. That authenticated user session is given a role called 'SQL Developer,' so if your REST API was protected via privilege that was also put into the 'SQL Developer' role, it would get authorized.
We don't recommend this for a few reasons.
One of the biggest is how much slower it is. We have to make an actual database connection to ensure your user/password combo are correct. That takes TIME.
Hence, we point folks to OAuth2, or something higher up the stack like an API Gateway.
Coming later this year, we'll have out-of-the-box support for OpenID. This will add tremendous amounts of flexibility without sacrificing security or performance.
Disclaimer: I work for Oracle and am a product manager for ORDS.
Should I have one login form for ordinary user and admin
Or
should I have separate login form for admin and ordinary user?
It is OK to have the same form.
The purpose of the login page is authentication-- determine who the user is, not what they can do (see What is the difference between authentication and authorization?). So for example you might want them to submit a password or other token to reduce the risk that they are not the person they say they are. That can be the same process for everyone.
Certain features in your site may be available only to administrators or end users, but checking for permissions (authorization) can only be done after you're sure who the user is (they have authenticated). And logic to check for permissions should be present on every single page. So it has little bearing on what the authentication process is like.
You should just use one form for both admins and ordinary users if the log in information required is the same. Having two forms only makes the application more complicated to write. Having one or two login forms would be equally safe. Just remember to implement the correct security measures on the server side so a user does not get admin privileges.
The first step in authentication would be to check if the username exists, then check if the entered password matches the user's password in the database (passwords should be hashed). Then you can do authorization to check if the user is an admin.
While this seems to be asked in the form of an opinion, it makes more sense to answer this based on what most websites (or applications) do.
It really depends on the context. As a general rule, the same login form would be used for regular users and admin users. Generally, a parameter specifying whether the user is an admin would be stored in a database table for the users. The authentication method(s) that are executed upon clicking the login button will verify the user exists, check the password against the hash, then check the database table to see if the user is an administrator.
In some certain circumstances, I have seen a separate login page for administrators, but it is rare. One example might be a webstore that has an administration/management dashboard which is separate from the main site. Generally, though, these will work via the same form.
I'm new in LDAP. Perhaps the question may seem strange, but on the internet I have seen different versions. Please, help to understand which way is the correct authentication via LDAP. I have an LDAP-directory where user passwords are stored as hashes. I know two ways to authenticate third-party applications using the LDAP-directory:
Authentication check on the LDAP side. Using the “bind” function the DN and password of user are passed in plain-text. If the bind is successful user authenticate, otherwise doesn't.
Authentication check on the application side. Using the function “bind” we connect to the directory as an admin. We are looking for the right user and get his record. We parse password field, isolating the type of hash algorithm (e.g. {CRYPT}). We make hash of the user-entered password with proper algorithm. If the hashes are the same then the authentication is successful, otherwise not. (That is, the application must maintain an appropriate hash algorithm).
Which option is the most correct? And which way is considered a standard for any-vendor systems which claim support for LDAP-authentication?
You'll want to use Option 1!!!!!
Option 2 has some disadvantages:
You'll need an admin account that can read the passwords to be able to compare them to the one you hashed. That means that the application is able to read the password hashed. I'd consider that a bad idea.
You'll circumvent additional security measurements implemented. The password you are checking might be the right one. But due to other policies the user might be locked and should not be able to login. And failed attempts will not count towards a possible lockout.
The hashing algorithm might change in future to one you haven't implemented yet.
You might be able to circumvent those obstacles but you will need aditional code to implement that. And that effort has already been taken and is readily availabel when you use option 1
I am developing an iOS app that is password protected and all the users are stored in a wordpress account that, of course, is password protected as well. Does anybody know the format that wordpress uses to store login information for these accounts, I would assume that it is a MySQL that sends a json? I have only been able to find the database code for the initial admin page but nothing that shows the way these accounts (815 to be exact) would be stored within the site.
The raw data is in the wp_users MySQL table.
The (default) code WordPress to authenticate users in the wp_check_password function. It's possible (though unlikely) that the password is a straight MD5 hash (I assume that check's just for backwards compatibility). Usually, it'll be encrypted using the PHPass library (see here for the WordPress code).
As far as I know, there's no API for checking a password that returns JSON. You'd probably have to write something yourself. This question suggests the wp_authenticate_username_password would be the best way to check the username / password combination on the server.
i have to create a login module (The question is not language specific) but i am not sure how will i validate the user. Where and how will i store the passwords. Will i have to encrypt and decrypt my passwords and if yes what are the best suggested way to do them. Overall i need to know what all things i need to take care of for developing a login module where a user can login securely to access my site.
You don't need to decrypt your passwords in order to validate them, just one way encryption works fine for this. The idea is that when a user enters a password, you encrypt it the same way (using the same algorithm and "salt") and then compare with the encrypted one stored in your database. If they are equal, with a great probability it means it's the same original password. Thus you prevent anyone - the adminstrator or any attacker - from knowing the original passwords users use on your web site.
As for the rest, it's very simple, you have a table in your database which contains user logins, encrypted passwords, and possibly some profile information as well (full name, etc).
I usually use the following function to hash user passwords:
$password_hash = sha1(MY_SALT_1 . $login_name . MY_SALT_2 .
$password . MY_SALT_3);
where MY_SALT_* are arbitrary predefined strings, could be e.g. 'the dark', 'side of', 'the moon' (or actually the less related - the better).
Yes.Sure you need to encrypt users passwords.Because most of the users using the same password almost all sites.At that time they are not want to show the passwords to admin.And another reason is most of the time the site DB may be accessed not only by admin.Some other technical persons in the organization.So it is better to encrypt the password.SHA1 is the best way to make the encryption.
Where and how will i store the passwords.
I am not sure what you mean by this.Every one use the database for it like phpmyadmin.