On Mon, Jul 9, 2018 at 6:19 PM, Gregg C Vanderheiden <[email protected]> wrote:
> > > On Jul 9, 2018, at 1:12 PM, Steven Githens <[email protected]> wrote: > > Just a couple notes inline: > > On Jul 8, 2018, at 8:46 PM, Gregg C Vanderheiden <[email protected]> wrote: > > *OOPS - forgot to ask at the end. **Are you ok with the plan with this > additional information? * > > *We do need to do some work to implement this — but it is a lot less than > securing the AWS or trying to get Google up and secure. * > > *If everyone is ok - then we need to scope this out - and see just what is > needed and book it. * > > *I will write it up in more detail if this looks good as a > general approach - and we can examine it in more detail. * > > > In general I think it's good, because I'm partial to having some > additional dev and testing resources put in to our default Cloud Safe > logins and key setups. > > I'm not completely sure the issues surrounding why we won't feel > comfortable putting the emails on AWS outside of ferpa environments, but I > know there are a lot of logistics and things being worked out by the ops > and logistics team. > > > *GV2: That server does not have multilayer security — and emails are not > good to distribute but not too bad. However if they use their own > passwords - we are then responsible for them in break in. We would of > course hash them but not sure if that is completely reliable. Would like > to see some pro and con articles about security of properly hashed > passwords. * > Not entirely certain what you mean by "reliable" in this context, but generally, the use of a strong, tunable-performance hashing function (meaning that the hashing function can be made to be very slow, but not so slow it destroys the performance of the webserver overall; the rule of thumb around this appears to be "takes 50-100ms on your hardware"), along with a cryptographically-secure pseudorandom salt, is considered a robust security measure (defined as "we lost your passwords but you shouldn't worry unless your password was 'password'"). For which hashing algorithm: I'd pick scrypt, unless you have robust libraries that you'd like to use that only support bcrypt, in which case bcrypt is fine (but the number of rounds will likely need to be more than the default). Argon2 seems to be a new recommendation which is likely also fine, but I'm not enormously familiar with it. For any of them, picking the cost factor to make it time-consuming (or in the case of scrypt, time and memory-consuming) to check passwords is the goal (so that an attacker cannot efficiently parallelize and attack even a complete dump of your password database); using a strong but incredibly fast hash (like SHA2 or SHA3) makes it easier to attack your passwords in an efficient way. OWASP has an OK overview of this at https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet, and https://security.blogoverflow.com/2013/09/about-secure-password-hashing/ is a very well-written overview that likely has more depth than you care about (but it's useful to understand the threat model). ---Brendan O'Connor
_______________________________________________ Architecture mailing list [email protected] https://lists.gpii.net/mailman/listinfo/architecture
