So I have this site running under ssl (on siteground).
The site is new, the instalation has no more than 2 weeks.
I have a working desktop app to connect to my sites, using jwt tokens, but the plugins for this token are old and has not being tested with newer WP versions. So to keep everything up to date, I want to change to this kind of auth.
But when I try my site, using get over the rest-api, I don´t get the authentication key according to this.
So I think that app passwords are not enable by default.
If that is the case, according to that page, I have to add:
add_filter( 'wp_is_application_passwords_available', '__return_true' );
somewhere, but I don´t know where to add it.
Or is this something else I have to be cheking?
www.example.com is built with WordPress.
www.example.com is always redirected to
alumni.example.com/?page_id=175/, however I don’t remember how this redirection is set.
I wanted to sign in the dashboard of WordPress, but my username and password did not work anymore (for long time I did not sign in). I tried to find my password, but the following page just hanged.
Does anyone why finding lost password does not work? Is it related to the redirection? Is there other way to sign in?
I have a page at https://sportysacademy.com/cfi/ when I enter the password for the password protected page, I get redirected to https://sportysacademy.com/wp-login.php?action=postpass with the error message
Error: The username field is empty. Error: The password field is empty.
Any ideas as to why that’s happening? I’m at a loss.
I’m developing a website there the users are going to have access to their own data. I’m gonna use a specific authenticator called BankID which is widely used in Sweden, a kind of extern authenticator (as an app in the mobile phone). The user completes the authentication process via mobile phone and we get a success response when the auth process is over. But then I want the user to be redirected to the WordPress user-dashboard just like a user that has normally logged in to WordPress. What is the easiest way to do this?
I’m stuck in a situation where I need to create a new user for a partially-contained database (SQL Server 2016). The password is short, so I get an error:
Password validation failed. The password does not meet Windows policy requirements because it is too short.
When creating a login at the instance level, there is an option to untick ‘Enforce password policy’, ‘Enforce password expiration’, and ‘User must change password at next login’. There is no such option when creating a user for a partially-contained DB.
Is there a way to get around this?
There is a page where the username is a number and the password is the last 4 digits of that number, I need to know if there is an option or a way to automate it with Hydra or another tool for not have to be entering one by one.
This question is inspired by Is there any security risk in not setting a maximum password length?.
Specifically the accepted answer https://security.stackexchange.com/a/238033/9640 says limits are recommended to avoid exhausting the server.
Also it seems to me that if the server is hashing your password to a n digit hash, there is no security advantage to having a password that is longer than n digits. An entity that could reasonable brute force the n digit space, would not have to brute force the (n+1) digit space to brute force your (n+1) digit password. In practical terms, a 1000 digit password is not really more secure than a 500 digit password.
However, what about double hashing the password.
- The user enters a password of arbitrary length.
- The client hashes the password to a fixed length.
- The server can reject the client’s hash if it is not the fixed length (protecting the server from resource exhaustion).
- The server otherwise treats the client’s hash as the password and proceeds in the usual manner (it re-hashes it).
In this way, if you want a 10,000 character long password go for it. Your browser will invisibly to you, transform your 10,000 character long password to a 128 character long password (still very secure) and the only change in the server is that now the server knows that all passwords must be exactly 128 characters long so it can reject some logins more easily.
The primary benefit of this scheme is that no user will ever be told "your password is too long". I personally find this message to be disheartening. But I concede that this benefit is not monumental. So if there are any security holes that I am not seeing, this scheme is probably not worth it.
Last days I’ve received multiple password recovery attempts for a WordPress user. The user didn’t initiate these attempts.
I’m blocking the IP’s on the server, but I don’t see what the goal of the attacker is. I checked the mails the user receives, and they contain a valid password reset link (so no phishing attempt).
So I don’t really understand what the attacker is trying to achieve with these password recovery requests. Or are they just checking for vulnerabilities on that page?
I’m a listener of the podcast "Security Now" where Steve Gibson, a security expert, often claims that there are no reasons to limit the number of characters a user can use in their passwords when they create an account on a website. I have never understood how it is even technically possible to allow an unlimited number of characters and how it could not be exploited to create a sort of buffer overflow.
I found a related question here, but mine is slightly different. The author of the other question explicitly mentions in their description that they understand why setting a maximum length of 100000000 characters would be a problem. I actually want to know why it would be a problem, is it like I have just said because of buffer overflows? But to be vulnerable to a buffer overflow, shouldn’t you have a sort of boundary which you can’t exceed in the first place, and thus if you didn’t limit the number of characters, would you even have this risk? And if you are thinking about starving a computer’s RAM or resources, could even a very large password be a problem?
So, I guess it is possible not to limit the number of characters in a password: all you’d have to do would be to not use the maxlength attribute or not have a password validation function on the server side. Would that be the secure way to do it? And if it is, is there any danger in allowing an unlimited number of characters for your passwords? On the other hand, NIST recommends developers to limit passwords to 256 characters. If they take the time to recommend a limitation, does it mean there has to be one?
NIST SP 800-63b gives the following guidance for password forms (aka login pages):
Verifiers SHOULD permit claimants to use “paste” functionality when entering a memorized secret. This facilitates the use of password managers, which are widely used and in many cases increase the likelihood that users will choose stronger memorized secrets.
In order to assist the claimant in successfully entering a memorized secret, the verifier SHOULD offer an option to display the secret — rather than a series of dots or asterisks — until it is entered. This allows the claimant to verify their entry if they are in a location where their screen is unlikely to be observed. The verifier MAY also permit the user’s device to display individual entered characters for a short time after each character is typed to verify correct entry. This is particularly applicable on mobile devices.
I had the argument made to me that these two features should not be implemented together because they would allow a user to circumvent a password manager’s protection and view the auto-populated password. I suspect this argument won’t hold water, but I’m curious about community opinions.