Notes: React Native - Uses expo.dev tooling, which is commercial, but does have a free tier.
[comment deleted]tracker1 930 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.
Yeah, totally understand keeping it simple... and visualizations should probably be externally injected via plugin anyway to keep payload smaller where not needed.
Webamp uses butterchurn, for reference.
https://github.com/jberg/butterchurn
Pretty nice overall... semi-mixed feelings about the css customization vs a theme property, but it is closer to the browser's intended use for this.
Would be cool to see this extended with some visualization support like the webamp.org player.
It's interesting... First look and the example todo app are pretty easily understood... I'm still not sure how I feel about decorators defining UI integrations, though it appears at least at first glance much better than say Angular's approach. It's been a while since I looked at Vue, so don't recall it well enough to draw comparisons there.
Generally speaking, however, I've been really happy with the react-style component approach, especially with hooks and functional components. I've taken to using more of an MVC style approach with a controller to handle events and generate actions, then passing state change actions to a reducer (redux). It's not quite the prescriptive approach, but has made state very testable.
All of that said, it's nice to see new approaches... I'm curious how the yaml front matter in the .mahal files plays into things, since I didn't try running the application, but if it integrates with some sort of in-browser tooling extension, that could be very cool.
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