151–160 of 405 posts
Earlier quoted context omitted.
No, the system isn't secure. The text of the password should not persist.
Who said the text persists, you could take it off the phone and type it in to compare against any existing salted hash. Still not good security, but not necessarily stored in plaintext.
Hmm, sorry but I don't buy that the "correct way to validate" is not to validate the input. Email addresses aren't a special enough case to be handled differently than any other user input, which we always validate to both sanitize and show client-side errors, if nothing else. Sure, the complete regex is complex, but it is defined and is hardly unconquerable. Look at Django's `EmailValidator` implementation for examp…
Also whether you use RegExp on email or not totally depends on what you're doing with the address. Are you throwing that email into Salesforce? Great! Salesforce does RegExp validation on all email addresses and the field is required. You _HAVE_ to do it. Solution? Use the same validation that Salesforce does. That's what I do.
Also the OPs math about how common invalid email addresses are is wrong. Do you know what the most common way of screwing up an email address is? Hitting tilde when you're tabbing away from the field. And that error is in the tenths or hundreds of a percent range (which is still significant). I have a dataset of 5MM email addresses typed in by jaded call center agents to prove it.
Earlier quoted context omitted.
Or when a password that is generated by my password manager is rejected with a message "Password should be 12 characters maximum". Why???
Even 15, 16, 31, or 32 (all of which I've seen before) would make more sense. 12 is "odd".
The number of websites that try reject my email address with a + in it, ugh! Surprisingly, the validation is often done 100% client-side anyway, and simply modifying the incorrect regex lets my email address through... If I wrecked havoc on your back-end, then it's your fault for sucking ;)
Earlier quoted context omitted.
Or when a password that is generated by my password manager is rejected with a message "Password should be 12 characters maximum". Why???
Ha! If only! Probably more than 50% of the sites I visit that have a maximum length that my password manager exceeds... give me an unrelated error message. Some times they tell me I haven't met the minimum length (100 chars, really?), sometimes they tell me that I've not met complexity requirements (I use upper/lower/numbers/special chars), etc. It's as though the developer only ever thought of how people wouldn't me…
Hmm, sorry but I don't buy that the "correct way to validate" is not to validate the input. Email addresses aren't a special enough case to be handled differently than any other user input, which we always validate to both sanitize and show client-side errors, if nothing else. Sure, the complete regex is complex, but it is defined and is hardly unconquerable. Look at Django's `EmailValidator` implementation for examp…
> Sure, the complete regex is complex, but it is defined and is hardly unconquerable. If it is a regular expression, then it is not able to match all valid email addresses, because the grammar of email addresses is context-free, and regular expressions can only match regular grammars. It doesn't matter if it is defined or not: if it's a true regular expression, then it simply cannot validate email addresses. (it may,…
2. For immediate feedback, you can reasonably check it's not at at a non-routable IP range, ie. address@127.x.x.x or address@192.168.x.x or similar. However, this check is best done on your email server (MTA policy). It's unlikely anyone would enter this without malicious intent so there's no need to optimize for their use case.
1. International domain names... you cannot filter characters much because of this. If you want to filter characters, be damn sure it's careful and precise filtering. 2. For immediate feedback, you can reasonably check it's not at at a non-routable IP range, ie. address@127.x.x.x or address@192.168.x.x or similar. However, this check is best done on your email server (MTA policy). It's unlikely anyone would enter thi…
Email validation is simple. You take the full RFC regex, and remove the notations permitting square brackets and comments. You wind up with a regex that accepts exactly 100% of real-world email addresses. If your regex contains "\.(com|org|...)", you're doing it wrong.
If you can't figure out how to do the full regex properly, then match against /^[^@]+@[^.]+\./ - or hell, just check for an '@' symbol - as a basic "hrm that kinda looks like an email address" and send the email. It's really not difficult. The only problem is naive English-speaking people who only deal with latin1 thinking that [a-z0-9]+ is somehow the only valid criteria for a username or hostname.
Hmm, sorry but I don't buy that the "correct way to validate" is not to validate the input. Email addresses aren't a special enough case to be handled differently than any other user input, which we always validate to both sanitize and show client-side errors, if nothing else. Sure, the complete regex is complex, but it is defined and is hardly unconquerable. Look at Django's `EmailValidator` implementation for examp…
I'd never looked closely at Django's email validation, but after looking at it I'm inclined to stop using it. Example reason:
> # max length for domain name labels is 63 characters per RFC 1034
There is a high likelihood that most of your users have shorter domain names, and also a high likelihood that most if not all registrars currently enforce this. But it also used to be highly likely that domains didn't begin with a numeral, and even though it was disallowed, 3m.com existed.
Another: neither the tests nor the patterns account for unicode, which is valid for domain names irrespective of the local part, and if not allowed for the local part by existing providers almost certainly will be eventually.
Also, a thing I noticed in the Django tests that is just upsetting:
- name: `TEST_DATA`
- values: `(validator, value, expected)` (a validator of the data is not the data)
- unstructured groups of such that should almost certainly be structured
The number of websites that try reject my email address with a + in it, ugh! Surprisingly, the validation is often done 100% client-side anyway, and simply modifying the incorrect regex lets my email address through... If I wrecked havoc on your back-end, then it's your fault for sucking ;)
Even worse is rejecting my password because it has a + in it! Why do you as a business care what my random password generator spit out?? Scarier still is when it's a server-side response that rejects my password for its contents...
I tried to explain to my boss why this was such a terrible idea and he was not hearing any of it.