8👍
You should always assume that the attacker has access to your password generation scheme. Basing your security on the assumption that he doesn’t is trusting security through obscurity. Obscurity can give a nice security bonus but you should never rely on it.
You must assume the attacker knows the content of both lists. For example he can simply register about 40 times, and then knows a significant part of them.
Your car-names combined with the verbs have about 9.6(=log2(20)+log2(40)) bits of entropy. Corresponds to about 2 random characters. That’s very low.
3👍
Can you force a password change the first time a user logs in? Or, if all your users have already been logged in, force a password change the next log in? That way, you can keep the more secure passwords and users can’t complain about the randomly generated password being hard to remember because they have to change them to something they do remember.
- [Django]-Crispy-forms InlineRadios don't show my model state
- [Django]-Django SQLite foreign key mismatch error
3👍
How about using an OpenID system, so they don’t have to remember yet another password. There’s some Django integration on the interwebs. The downside is that you’ll need to know their OpenID in order to add them to the auth DB before you send out the invites…
- [Django]-Redirect realtime common line output to Django HttpResponse
- [Django]-Django Admin Remove default save message
- [Django]-Django SESSION_COOKIE_DOMAIN
- [Django]-Django Model API reverse lookup of many to many relationship through intermediary table
- [Django]-How to add russian language support to Django CMS?
1👍
The Concept of doing a random password generation as far as you have a flag stating which random password generation pattern used for generating the password as you need to check the password in later sign ins.. are you doing that? If yes then add a salting pattern to make it secure and finally a hash of the overall salt generated will be more safe. Try this ..