On Mon, Apr 22, 2019, at 20:18, whitehexagon via golang-nuts wrote: > Also good to know only what I'm using gets linked in, but then the > size of 'hello world' is even more surprising.
That's because the runtime is being linked in. Go requires, among other things, a garbage collector and goroutine scheduler. These things are always linked in because you're always using them. > The argon2 looks interesting, but it sounds like it could be very > memory heavy. The code I'm porting is running on a PAAS/SAAS setup, > and that might have cost implications exceeding the worth of my low > value data. But I will also have a look then at the sha3 that was > mentioned, now that I know the 'x' stuff is internally produced by the > same team! Being memory heavy is the point; you don't want a fast hash to protect your users data or if the hashes ever get stolen it's much easier for an attacker to brute force them. SHA3 is a great hash, but it is not appropriate for password storage. Please don't put your users passwords at risk just to lower your operating overhead. > I get the impression from some of the info I'm going through, that > since I'm running on hosted systems, which optionally also have > encrypted file systems, that some of the brute force defense stuff > might be less applicable? This is not true. An encrypted filesystem only prevents your database from being stolen by eg. someone coming into your datacenter and running off with your hard disk. It is no substitute for storing passwords correctly. > ie unless the database is physically stolen from some nuclear bunker > somewhere in the world, and decrypted, and my noddy system is deemed > worth hacking, it's probably pretty safe already. Please don't put your users passwords at risk because you think something you've done is "good enough". Always follow password storage best practices. > So the main attack vector would be multiple login attempts, which I > can detect fairly easily. for example, 5 failed logins and the account > is locked... That's one way, and you should be doing that. However, you are human and will make mistakes so another attack vector is someone managing to dump your database, or getting in some otherway and downloading it. > I was also thinking in this case I could use a client side hash so > that the backend system never see's a plain text password. I realise > of course that the hash becomes the password, but at least the hosted > environments would never see clear text before reaching my hosted hash > stuff. ie clients that reuse 123456 for everything :) This generally isn't necessary and probably doesn't add much since you're not likely to have your passwords stolen out of memory. Just follow industry standard best practices. —Sam -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
