Disclosure: I work for the referenced company, and I'm not sure how to get the suggestion in this post across without it seeming like a sales pitch. Here goes.
It seems to me that "memorized passwords" and "our average user is over 70" are not going to play well together. Have you considered solutions other than passwords? You'd want ...
I know this doesn't entirely answer the question as asked, but another approach is to accept that, given your user community, a breach will happen sooner or later, and move instead to minimise the harm that then occurs.
You write that your app "helps them collect and submit physiological data to their doctors". Why, then, does the app have to ...
It is no secret that a lot of people who are tasked to design security for systems know very little about information security and are ill equipped for the task. As a source for that claim, I will take years of personal experience as pentester, and the absolute bewilderment for the things I have seen people develop over the years. Not because the ...
Have them bring their phone to the doctor's office to pair it.
The (non-technical, but trained) medical professional verifies the patient's identity (which they should do already?), and links the phone app to the system using a QR code, a one-time password, or whatever mechanism you prefer.
Then, the phone saves those credentials and doesn'...
Suppose you've decided that "At least 8 characters, 1
symbol, 1 number, etc." is suitably random, but results in impossible-to-memorize passwords.
There are about 70^8 possible 8-letter passwords (assuming 52 letters, 10 digits, and 18 symbols). This offers 5.8e14 passwords.
A password generated randomly by concatenating 4 words from a list of 100,...
I don't see to how your proposal is better than existing client side hashing approaches, but I find it as more complex to implement than others. Unfortunately you don't describe a specific risk you are trying to access so I just assume the typical threats commonly seen.
Man in the Middle attacker
In this case it is assumed that some man in the middle has ...
FORGET COMPLEXITY - even the NIST has moved away from that. Length beats complexity.
For your seniors, neither is useable. They typically type slowly and their memory isn't the best anymore. Thinking they can remember YuVM5nUf%ui? correctly is delusional.
You need to think a bit sideways here. Check your threat model - what is the danger of someone with ...
This is exactly the problem that protocols like PAKE and SRP aim to solve. With PAKE/SRP, the client and the server mutually authenticate each other based on a password known to the client (and a derivation of the password known to the server).
The client demonstrates to the server that it knows the password, without the client sending the password (or ...
What percentage of your clients carry smartphones? Do you think they would be able to use a "passwordless login" system with their phone? (i.e. FIDO)
All the FIDO systems use a one-time initial registration process, which consists of installing an app on the client's mobile device by scanning a QR code printed in an instructional brochure. That's ...
In addition to the answer of Steffen Ullrich:
If during login the user sends the hash only, then the attacker does not need to know the password. It is sufficient to steal the password database. Then during login request the attacker will just send the hash from database. The server will not distinguish if client used the password and hashed it, or if the ...
Was typing in my password into an HTTPS website
When I type in
Can the internet provider see it just like that?
Typically, no. The application-layer data you mentioned (username/password) is encrypted via Transport Layer Security (TLS) as it is passed from the application-layer to the transport layer.
In principle, only the web ...
I do not quite understand how it is common policy in industries to
require a difficult to remember password with different alphanumeric
and special characters that also has an upper limit of 32 characters.
Wouldn't it be easier for everyone to remember the password if the
lower character requirement was 32 and there was no requirement for
One problem with passwords is that if they can be broken as follows: pick a random password; hash it; compare that hash to other known hashes. This way, you have broken the code.
It was long ago that type of password mechanisms were used. Today we use random salt per password, and additionally, a server-based pepper. Then the user's password is hashed using ...
The way this is usually done where I am is by asking the user to enter their name and date of birth, and then sending a 4-digit or 6-digit SMS verification code to the phone number associated with the account.
So the username and password are just their name and birthday (easy to remember), and the 2FA is the SMS code (and if they're using an app to view/...
Where a traditional brute force would take m^n computations, a quantum computer would use √(m^n) computations, using Grover's algorithm. Using a password that is twice as long, or using twice as many bits in symmetric encryption give adequate protection against quantum computers.
For asymmetric algorithms, this is different. Using Shor's algorithm, RSA ...
How password_verify can know the algorithm used, the salt and the
$save_hash looks like this:
Which is a bunch of fields separated by $:
Type of hash, in this case bcrypt
Salt and password hash
The first 22 characters are salt, the remainder is the hash
If the attacker compromised your server, they are in control not only of the software running on your server but also of the software running on the clients.
No matter what beautifully engineered authentication scheme you designed, the attacker can alter it before it's sent to the browser.
You now have an egg-chicken problem: you can't secure a password if ...
If you don't have access to read the server configuration, the easiest way to check is to require the use of TLS on your client and see if you're able to connect successfully. This is done through the sslmode parameter key word. For example:
$ psql "host=184.108.40.206 port=5432 dbname=mydb sslmode=require"
After you have verified that TLS is ...
I think you may be getting confused with server-side password hashing. Server-side password hashing is essential for any system worth its salt (pun intended), to prevent users' passwords from being leaked in the event that the user database is compromised. But, it only works because the server just needs to verify when a client provides a correct password; ...
Smartphone users, use a password manager.
Others use a communal computer which prints 2 or 3 pieces of paper with a strong enough random generated password, 10-20 characters long.
Client stores paper in a secure location.
The client's trusted 2nd person stores paper in a secure location.
Management of elderly home store paper in a secure location.
I for ...
With the forgot password link your user can prove to have access to "something you have".
I would allow the reset of the account but would check more details like access to a second authentication factor (U2F, SMS, phone call, recovery codes).
You should also moderate this account. Only allow basic interaction and force additional authentication / ...
As @hft's answer points out, no, your ISP typically cannot read HTTPS traffic. However, they can tell the length of traffic sent each way (possibly not precisely if a block cipher is used), which is sometimes enough to determine some things about the encrypted traffic. They can also see when data is sent each way - how many requests (and responses) are made (...
What is the motivation for administrators to launch services with SPN
from domain user accounts?
There are five ways you can set these things up:
Local service on a workgroup machine
Local user on a workgroup machine
Local service on a domain joined machine
Domain user on a domain joined machine
(g)MSA on a domain joined machine
There is a collective ...
According to Raymond Chen at Microsoft, even version 4 GUIDs used in Windows since 2000 are not cryptographically secure. They use the basic random number generator, which can allow someone to predict past and future GUIDs if they know the state of the generator. Granted, this would only be relevant to a security-sensitive application. It's important to know ...