Validating emails with regex should have a couple guard rails...
First, you should check for length, if it's too long, then you can get some performance issues in practice.
Second, you should actually look at what valid emails can be... you can use a quoted User portion, but that may not match what you want to allow. The Email address spec is actually more broad than what general SMTP email allows to be delivered for internet email. YMMV of course.
Beyond this, will generally want to add secondary checks for domain portions/lookup as well.
Disclosure, I did used to work for a company that assigned profile values based on email address as an optionally single verification param (social media association, domain popularity, registration time, etc) to flag potential scam entries for additional scrutiny etc.
Why would you publish a ruby script to npm?!? There's no guarantee that someone with npm/node (especially in windows) has ruby installed or configured, or is running an environment that can even use a shell script.
Beyond this, node/npm has a concept of "binary" modules to add the command when you do a global/local install. This is just so wrong in so many ways.
https://guides.rubygems.org/publishing/
I'm not sure what advice to give here... I spent the past year dealing with very similar friction in my job, and am about to start a new one.
In the end, part of this is about education... refer the people in question to articles surrounding how these things work.
Notes: React Native - Uses expo.dev tooling, which is commercial, but does have a free tier.
[comment deleted]tracker1 813 days ago. link 2 points ▲▼
One thing I like about bcrypt is that the output includes the data necessary for comparison (rounds, salt, etc). Down side is it's not quite in the box in terms of a solution.
Alternatively, may want to use pbkdf2 with a high iterations (10k-100k) and keep the salt/iterations in the stored output.
I'll usually do something like the following in an NVarChar(500) field...
v#:details-base64:salt-base64:hashed-base64
Where I keep the version number of the hash implementation, so I can iterate and roll forward, the details for the hash, iterations, etc, the salt bytes in base64, and the hash output in base64.
Also, it's best to normalize the input (NFKC) before hashing. [1] Also, worth considering, if a hash attempt fails, and the last character is a whitespace character, try again with that last whitespace character removed (windows copy/paste). Beyond this, a random delay of 500-2500ms on failure before returning the error to reduce attacks.
There are other considerations as well... serializing requests from a single IP, rate limiting, etc... since strong hashing algorithms and authentication in general are a potential DDOS vector, beyond just the risk of entry.
1. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/normalize
Given how old and widely supported these methods now are[1], I'm not sure how much value this actually has.
Also, there's no real need to set an internalized value and break, just as easy to return false immediately in the loop.
1. https://caniuse.com/mdn-javascript_builtins_array_every
Curious to see if/how well this works with Deno, which I've been using far more lately for shell scripting environments, given it tends to be more easily portable.
One thing I like about bcrypt is that the output includes the data necessary for comparison (rounds, salt, etc). Down side is it's not quite in the box in terms of a solution. Alternatively, may want to use pbkdf2 with a high iterations (10k-100k) and keep the salt/iterations in the stored output. I'll usually do something like the following in an NVarChar(500) field... v#:details-base64:salt-base64:hashed-base64 Where I keep the version number of the hash implementation, so I can iterate and roll forward, the details for the hash, iterations, etc, the salt bytes in base64, and the hash output in base64. Also, it's best to normalize the input (NFKC) before hashing. [1] Also, worth considering, if a hash attempt fails, and the last character is a whitespace character, try again with that last whitespace character removed (windows copy/paste). Beyond this, a random delay of 500-2500ms on failure before returning the error to reduce attacks. There are other considerations as well... serializing requests from a single IP, rate limiting, etc... since strong hashing algorithms and authentication in general are a potential DDOS vector, beyond just the risk of entry. 1. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/normalize