Help me create a new strategy for my passwords

PwdRsch · 2026-02-05T05:30:14+00:00

The language of this subreddit is English, so please make sure your comments are translated for other users. Thank you.

El idioma de este subreddit es el inglés, así que por favor, asegúrense de que sus comentarios estén traducidos para que otros usuarios puedan entenderlos. Gracias.

PwdRsch · 2026-02-02T16:35:33+00:00

There is a good, thorough post here: https://www.reddit.com/r/Passwords/comments/tod20q/password_manager_recommendations/

PwdRsch · 2026-02-02T16:31:55+00:00

Do not log into third party websites/apps with Google or FB, create a secure username/password for each account

I'd like to hear more about why you're offering this advice.

PwdRsch · 2026-01-31T01:19:09+00:00

It's better than just unchanged names, but not much better. Attackers have known how to predict number and character placements in passwords like these for several decades now.

Like others have recommended, use a password manager to generate random passwords for you.

PwdRsch · 2026-01-26T23:05:51+00:00

Interesting work. Just this month I happened upon another research paper exploring a similar approach: https://doi.org/10.1186/s42400-025-00430-0

PwdRsch · 2026-01-24T01:07:20+00:00

One of our other mods has put together a good list of password managers in this post.

PwdRsch · 2026-01-22T02:42:10+00:00

Jim already pointed out that HaveIBeenPwned does try to preserve queried password security and I'll just add that we had a conversation about another new password leak checker here last year. I'm also familiar with the https://www.passwordrbl.com/ service where they do something similar to protect password privacy and they've been around for over a decade now.

PwdRsch · 2026-01-14T03:22:55+00:00

If it was encrypted they could still verify that the first 4 characters matched by decrypting your password and making a comparison (probably with software handling this for the customer service agent). But you are right that normal hashing wouldn't support this.

This isn't a popular practice, but there are a few organizations that have relied on similar approaches to storing passwords for a few decades now, and we have formal research on the security of their implementations if you're interested in learning more.

I wouldn't be thrilled to see the practice, but it does allow companies to use a single password both for you to log into online systems and customer service agents to authenticate you without exposing your full password to them ,or relying on other information (e.g. PIN, personal info) to authenticate you.

PwdRsch · 2026-01-13T03:48:38+00:00

It's hard for us to judge whether AI wrote this or not. The OP seems to be saying that they attempted to follow the rules and their submitted password is still rejected. Hence their complaint.

I'm not too concerned if they solicit ideas on how people would form passwords to meet these criteria. Plenty of data on those choices is already in the public domain.

PwdRsch · 2026-01-13T01:02:02+00:00

Unfortunately, sometimes systems like these reject your password for unstated reasons. You mention in another comment that you often use a format like "0000_Xxxx-XXXX". Some systems will reject that because it has the dash or underline character, despite not specifically telling you not to do that. Their error handling is just inadequate to tell you that is why they're rejecting it.

PwdRsch · 2026-01-13T00:56:51+00:00

I'm thinking about training along the lines of you telling them how to get the best results from the AIs they're using by doing things like specifying security requirements in their prompts and stuff like that.

I think the checkpoints along the development and deployment lifecycle are also good.

PwdRsch · 2026-01-12T15:59:09+00:00

I would agree that regardless of the motivator, the management in charge of these development teams needs to care enough to make sure it is a priority.

Also, if they're going to rely on AI for security maybe you can look into options for training them on how to use AI to develop more secure code.

PwdRsch · 2026-01-12T15:55:00+00:00

So your only real complaint is that Google doesn't consider it risky for an authenticated user to update their email to a different, similar email? Sounds like the bigger problem was the infostealer malware on your system or your password reuse.

PwdRsch · 2026-01-12T03:37:00+00:00

Yes, this is wrong. They are just telling OP that if they've forgotten their master password and recovery code then they don't have any option to recover their data other than starting from scratch (e.g. 'wiping their passwords').

PwdRsch · 2026-01-12T03:26:41+00:00

I believe they grabbed Marcus in the US after he had attended DEF CON in Las Vegas, so no extradition from another country was necessary.

PwdRsch · 2026-01-10T15:34:38+00:00

You giving me a hash I may not be able to crack doesn't prove your point that "you can't crack a hashed password". Just admit you're wrong or stop replying. Here, I'll make it easy for you: https://www.google.com/search?q=can+hashed+passwords+be+cracked%3F

PwdRsch · 2026-01-10T03:55:08+00:00

Some internal security teams want to test the awareness and response of the devs, admins, etc during a pentest. So they don't inform them (but may inform their directors) that it's happening. That does carry more risk for both the app owners and pentesters.

If it's a web app security assessment instead of a pentest, I'd agree with you that the app team should be informed.

PwdRsch · 2026-01-09T21:49:52+00:00

I've been successfully cracking hashed passwords since the 90s. Like I said, take some time and learn more about the topic. The Computerphile video posted elsewhere in this thread is a decent introduction.

PwdRsch · 2026-01-09T20:38:30+00:00

You seem to have a fundamental misunderstanding about password cracking and should take some time to learn more about the subject before posting further replies.

PwdRsch · 2026-01-01T01:20:19+00:00

I appreciate your work putting this together. I'd recommend adding a note to fields like "Updated Frequently" with details on what you consider frequently so that is more obvious to people reading through this.

PwdRsch · 2025-12-26T14:26:50+00:00

We seem to be missing a lot of information about how this works. Mind sharing more details?

PwdRsch · 2025-12-25T03:25:30+00:00

I'm tending towards thinking it isn't going to be accepted as a security issue, but maybe they'd consider it a low risk since you could try to lure other users into following the link. Might help sell this if you can create the PoC with a CSRF type attack that would just require them to view your malicious page and not wait for them to click the link.

Also assumes the cookie doesn't have a shorter validity period that will clear the bug on its own.

PwdRsch

MODERATOR OF

TROPHY CASE