The Infosec Thread: Yes, time to move off LastPass

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Infosec Thread: Yes, time to move off LastPass

«‹›504 »

Lain Iwakura: Aug 5, 2004; The body exists only to verify one's own existence.; Taco Defender

skull mask mcgee posted:

The most damaging thing to come out of the leaks is the people claiming Signal and WhatsApp aren't safe because if someone owns the device they're on they can read your messages

Or that the smart TV nonsense requires physical access too.

None of this is earth shattering.

# ? Mar 9, 2017 19:00

Adbot: ADBOT LOVES YOU

# ? Apr 27, 2024 22:32

susan b buffering: Nov 14, 2016

OSI bean dip posted:

Or that the smart TV nonsense requires physical access too.

None of this is earth shattering.

I'm cool with any FUD about smart TVs because they loving suck anyways.

# ? Mar 9, 2017 19:10

Knyteguy: Jul 6, 2005; YES to love
NO to shirts; Toilet Rascal

How's this guide for password generation and storing?
https://crackstation.net/hashing-security.htm

My user table:

So I'm going for a slow hash, with a salt, and X number of iterations. Preferably using something like this: http://shawnmclean.com/simplecrypto-net-a-pbkdf2-hashing-wrapper-for-net-framework/

Is there a newer recommended C# library, or will PBKDF2 still hold up?

# ? Mar 9, 2017 19:22

Thanks Ants: May 21, 2004; #essereFerrari

On the subject of auth - is there a consensus of opinion on rolling your own user database / auth system vs. using things like Azure AD B2C, Firebase etc.?

# ? Mar 9, 2017 19:32

Twerk from Home: Jan 17, 2009; This avatar brought to you by the 'save our dead gay forums' foundation.

Thanks Ants posted:

On the subject of auth - is there a consensus of opinion on rolling your own user database / auth system vs. using things like Azure AD B2C, Firebase etc.?

I would not want to store passwords if I could at all avoid it, and there's lots of relatively cheap solutions that offload that from you.

# ? Mar 9, 2017 19:35

Lain Iwakura: Aug 5, 2004; The body exists only to verify one's own existence.; Taco Defender

https://twitter.com/Bugcrowd/status/839884929840386048

1Password is putting its money where its mouth is.

# ? Mar 9, 2017 21:04

B-Nasty: May 25, 2005

Modest Mouse cover band posted:

How's this guide for password generation and storing?
https://crackstation.net/hashing-security.htm

My user table:

So I'm going for a slow hash, with a salt, and X number of iterations. Preferably using something like this: http://shawnmclean.com/simplecrypto-net-a-pbkdf2-hashing-wrapper-for-net-framework/

Is there a newer recommended C# library, or will PBKDF2 still hold up?

Don't roll your own. Microsoft Identity has a hasher built in: Microsoft.AspNet.Identity.Core/PasswordHasher.cs. It uses PBKDF2 (1000 iterations) to generate a 128 bit salt and 256 bit key. It automatically adds a version number, appends those items together, and returns a nice Base64 string that you can store in the DB. It also has a VerifyHashedPassword method that does a constant-time comparison and (smartly) returns an enumeration of whether it passed or not.

The 1000 iterations is a bit low, but it shouldn't matter much for stronger passwords. The versioning they built in allows for MS to add additional algorithms and easily upgrade, though they haven't done it yet.

edit: They actually have updated it. Version 3 will use: PBKDF2 with HMAC-SHA256, 128-bit salt, 256-bit subkey, 10000 iterations.

B-Nasty fucked around with this message at 21:25 on Mar 9, 2017

# ? Mar 9, 2017 21:15

Knyteguy: Jul 6, 2005; YES to love
NO to shirts; Toilet Rascal

B-Nasty posted:

Don't roll your own. Microsoft Identity has a hasher built in: Microsoft.AspNet.Identity.Core/PasswordHasher.cs. It uses PBKDF2 (1000 iterations) to generate a 128 bit salt and 256 bit key. It automatically adds a version number, appends those items together, and returns a nice Base64 string that you can store in the DB. It also has a VerifyHashedPassword method that does a constant-time comparison and (smartly) returns an enumeration of whether it passed or not.

The 1000 iterations is a bit low, but it shouldn't matter much for stronger passwords. The versioning they built in allows for MS to add additional algorithms and easily upgrade, though they haven't done it yet.

edit: They actually have updated it. Version 3 will use: PBKDF2 with HMAC-SHA256, 128-bit salt, 256-bit subkey, 10000 iterations.

Oh very cool, that will work perfectly. Thanks.

# ? Mar 9, 2017 22:20

EVIL Gibson: Mar 23, 2001; Internet of Things is just someone else's computer that people can't help attaching cameras and door locks to!; Switchblade Switcharoo

B-Nasty posted:

Don't roll your own. Microsoft Identity has a hasher built in: Microsoft.AspNet.Identity.Core/PasswordHasher.cs. It uses PBKDF2 (1000 iterations) to generate a 128 bit salt and 256 bit key. It automatically adds a version number, appends those items together, and returns a nice Base64 string that you can store in the DB. It also has a VerifyHashedPassword method that does a constant-time comparison and (smartly) returns an enumeration of whether it passed or not.

The 1000 iterations is a bit low, but it shouldn't matter much for stronger passwords. The versioning they built in allows for MS to add additional algorithms and easily upgrade, though they haven't done it yet.

edit: They actually have updated it. Version 3 will use: PBKDF2 with HMAC-SHA256, 128-bit salt, 256-bit subkey, 10000 iterations.

One thing I liked one company did for deciding iterations is to pick an amount of time you are willing to have the user want. For our case, 3 seconds.

On the same production system create a script to run a hash starting with with default iterations and just add to that count (by a thousand ) and keep times until the acceptable time passed.

For a pdkf the default count is a thousand. We found 3 seconds of time on our system required 32000 or so iterations.

The system was then made upgradeable (whenever a user changed or reset the password) so if we got better systems the count was increased and we made sure the count could never be decreased.

It might be overkill but our organization had to protect information on people that not only had to be under the general standards but also HIPAA which is a loving bitch to work with sometimes.

# ? Mar 9, 2017 22:51

Lain Iwakura: Aug 5, 2004; The body exists only to verify one's own existence.; Taco Defender

B-Nasty posted:

Don't roll your own. Microsoft Identity has a hasher built in: Microsoft.AspNet.Identity.Core/PasswordHasher.cs. It uses PBKDF2 (1000 iterations) to generate a 128 bit salt and 256 bit key. It automatically adds a version number, appends those items together, and returns a nice Base64 string that you can store in the DB. It also has a VerifyHashedPassword method that does a constant-time comparison and (smartly) returns an enumeration of whether it passed or not.

The 1000 iterations is a bit low, but it shouldn't matter much for stronger passwords. The versioning they built in allows for MS to add additional algorithms and easily upgrade, though they haven't done it yet.

edit: They actually have updated it. Version 3 will use: PBKDF2 with HMAC-SHA256, 128-bit salt, 256-bit subkey, 10000 iterations.

I do not recommend PBKDF2 for password hashing. The purpose of that hash is to key stretch a passphrase for the purposes of using it alongside another cryptographic algorithm.

Instead I'd look into using either Bcrypt or Argon2 which are intended for password storage. The two links are for C# implementations.

Lain Iwakura fucked around with this message at 04:42 on Mar 10, 2017

# ? Mar 9, 2017 23:05

B-Nasty: May 25, 2005

OSI bean dip posted:

I do not recommend PBKDF2 for password hashing. The purpose of that hash is to key stretch a passphrase for the purposes of using it alongside another cryptographic algorithm.

Instead I'd look into using either Bcrypt or Blake2 which are intended for password storage. The two links are for C# implementations.

It's not the most ideal, but it is Microsoft's implementation that uses Windows' FIPS-compliant CSPs. It's also heavily tested by the millions of applications that use ASP.Net Identity.

I'm sure the libraries you linked are perfectly fine, but certain organizations might not want to use an external library over what Microsoft provides.

# ? Mar 10, 2017 02:00

Lain Iwakura: Aug 5, 2004; The body exists only to verify one's own existence.; Taco Defender

B-Nasty posted:

It's not the most ideal, but it is Microsoft's implementation that uses Windows' FIPS-compliant CSPs. It's also heavily tested by the millions of applications that use ASP.Net Identity.

I'm sure the libraries you linked are perfectly fine, but certain organizations might not want to use an external library over what Microsoft provides.

If you go over the actual document, there is no mention of password hashing--seriously, just search for the word "password". Certain organizations may not be comfortable going with libraries that are not what Microsoft provides, but it is erroneous to suggest that FIPS should be at play here.

e: I meant Argon2 and not Blake2.

Lain Iwakura fucked around with this message at 04:41 on Mar 10, 2017

# ? Mar 10, 2017 02:25

Hollow Talk: Feb 2, 2014

Speaking of hashing etc. What do people think about hashing emails? I have a tiny app that will likely not be used by very many people (if any), but I still would like to get things right from the beginning. I use scrypt for password hashing, and I don't really need to ever contact users of my own accord, so emails are only used for password recovery, in which case I need to ask the user to enter their email address either way. This made me think that I could scrypt emails just as well (like passwords), and just check the email they supply upon recovery against the one they supplied when registering. This basically results in two SQL tables, one with username (plaintext) + password (hashed) + salt + datetime, the other with username (plaintext) + email (hashed) + salt + datetime. Thoughts? Stupid? Alright?

edit: vvvv The "two tables" thing has other reasons and lets me neatly re-use a more general struct and function on the programming side. :sun:

Hollow Talk fucked around with this message at 23:28 on Mar 10, 2017

# ? Mar 10, 2017 22:42

Rufus Ping: Dec 27, 2006; I'm a Friend of Rodney Nano

I realise I'm not addressing your question but you don't need two tables for that

# ? Mar 10, 2017 23:19

Wiggly Wayne DDS: Sep 11, 2010

when you get compromised how are you informing your potential userbase

# ? Mar 11, 2017 00:31

Hollow Talk: Feb 2, 2014

Wiggly Wayne DDS posted:

when you get compromised how are you informing your potential userbase

By contacting them on jabber, I suppose. Maybe a forums post? Fair point, though.

# ? Mar 11, 2017 00:38

Rufus Ping: Dec 27, 2006; I'm a Friend of Rodney Nano

Hollow Talk posted:

The "two tables" thing has other reasons and lets me neatly re-use a more general struct and function on the programming side.

The hole just got 10 feet deeper

# ? Mar 11, 2017 01:52

Volmarias: Dec 31, 2002; EMAIL... THE INTERNET... SEARCH ENGINES...

Email addresses aren't generally considered secret, so I'm not sure what you're protecting against, save for password reuse on other sites.

# ? Mar 11, 2017 02:37

Hollow Talk: Feb 2, 2014

Rufus Ping posted:

The hole just got 10 feet deeper

Eh, not really. It just means I can use the same function for checking hashed emails and hashed passwords, i.e. the difference between these two, which I suppose becomes moot if I don't bother to hash emails.

code:

;; User, input+salt
(struct scrypt-hash (user input salt) #:prefab)

;; User, email+salt, password+salt
(struct scrypt-full (user email password salt datetime) #:prefab)

;; Calculate scrypt hash+salt for input
(define (scrypt-input->hash input #:length [length 32] #:N [N 16] #:r [r 8] #:p [p 1])
  (let ([salt (crypto-random-bytes length)])
    (scrypt-hash null
		 (bytes->hex-string (scrypt input salt N r p length))
		 (bytes->hex-string salt))))

;; Check whether scrypt'ed input matches provided scrypt hash+salt
(define (scrypt-check-hash hash input #:length [length 32] #:N [N 16] #:r [r 8] #:p [p 1])
  (equal? (scrypt-hash-input hash)
	  (bytes->hex-string (scrypt input (hex-string->bytes (scrypt-hash-salt hash)) N r p length))))

Volmarias posted:

Email addresses aren't generally considered secret, so I'm not sure what you're protecting against, save for password reuse on other sites.

I suppose that was the idea. But it seems it's unnecessary, so I will probably switch this to username (plain) + email (plain) + password (hash) + salt + datetime.

edit: And done, switched to plaintext emails now. :sun:

The two different structs remain (though the two tables have been consolidated into one), since those scrypt functions are also used for instances where people enter passwords for something else without having to supply an email address at all. Thanks for the comments!

Hollow Talk fucked around with this message at 04:56 on Mar 11, 2017

# ? Mar 11, 2017 03:49

Rufus Ping: Dec 27, 2006; I'm a Friend of Rodney Nano

I don't see how that code necessitates using two different tables for hashed email and hashed pw unless your ORM sucks

But anyway that code doesn't seem quite right to me. Surely you should be hashing the password attempt using the same scrypt parameters that the stored hash was generated with? (and then, if the login was successful and the scrypt parameters have changed, update the stored hash to use the new parameters)

This doesn't appear to be what your code does

To answer your original question, email addresses aren't really considered secret so just make sure they aren't trivially enumerable via e.g. your "forgot password" form

# ? Mar 11, 2017 04:55

Hollow Talk: Feb 2, 2014

Rufus Ping posted:

I don't see how that code necessitates using two different tables for hashed email and hashed pw unless your ORM sucks

But anyway that code doesn't seem quite right to me. Surely you should be hashing the password attempt using the same scrypt parameters that the stored hash was generated with? (and then, if the login was successful and the scrypt parameters have changed, update the stored hash to use the new parameters)

This doesn't appear to be what your code does

To answer your original question, email addresses aren't really considered secret so just make sure they aren't trivially enumerable via e.g. your "forgot password" form

Whoops, I forgot the function that generates the hash in the first place. :saddowns:

I added it in above. The functions are fine, by the way. Arguments in [] are defaults which could be overridden on a case-by-case basis, but yeah, they obviously have to be the same values for hashing and checking a given password.

The dual-table thing had nothing to do with incompatible types (I presume that's what you meant with ORM?), but it just meant that rather than having to calculate hashes separately before shoving them into a common struct and then writing them to a table, I saved each separately. (I cleaned that up with the move to plaintext emails just now.) Structs are lovely for reading from (since each field is directly accessible by name) but they are a bit of a pain to transform into one another, since you cannot simply append to say a scrypt-hash struct to get a scrypt-full struct like you could with a list. That's why it was easier to do them separately, rather than extracting from one struct to write into another. Structs are weird but they make a bunch of things so much more readable. Having an SQL function that takes a struct and gets the relevant fields via (values (scrypt-full-user x) (scrypt-full-email x) (scrypt-full-password x)) is a bit nicer than using a list and basically having a function that just reads (values (car x) (cadr x) (caddr x)) or (values (first x) (second x) (third x)) etc. Structs also automatically provide a constructor function as well as a check for that type, so they are neat in many cases and massively help readability, though lists are easier when it comes to transformation.

# ? Mar 11, 2017 05:13

EVIL Gibson: Mar 23, 2001; Internet of Things is just someone else's computer that people can't help attaching cameras and door locks to!; Switchblade Switcharoo

Hollow Talk posted:

Eh, not really. It just means I can use the same function for checking hashed emails and hashed passwords, i.e. the difference between these two, which I suppose becomes moot if I don't bother to hash emails.
code:
;; User, input+salt
(struct scrypt-hash (user input salt) #:prefab)

;; User, email+salt, password+salt
(struct scrypt-full (user email password salt datetime) #:prefab)

;; Calculate scrypt hash+salt for input
(define (scrypt-input->hash input #:length [length 32] #:N [N 16] #:r [r 8] #:p [p 1])
  (let ([salt (crypto-random-bytes length)])
    (scrypt-hash null
		 (bytes->hex-string (scrypt input salt N r p length))
		 (bytes->hex-string salt))))

;; Check whether scrypt'ed input matches provided scrypt hash+salt
(define (scrypt-check-hash hash input #:length [length 32] #:N [N 16] #:r [r 8] #:p [p 1])
  (equal? (scrypt-hash-input hash)
	  (bytes->hex-string (scrypt input (hex-string->bytes (scrypt-hash-salt hash)) N r p length))))
I suppose that was the idea. But it seems it's unnecessary, so I will probably switch this to username (plain) + email (plain) + password (hash) + salt + datetime.

edit: And done, switched to plaintext emails now. The two different structs remain (though the two tables have been consolidated into one), since those scrypt functions are also used for instances where people enter passwords for something else without having to supply an email address at all. Thanks for the comments!

You should be focussing on difficulty and not mashing stuff together because you can.

Your N is only 16. Default scrypt N is 16384.

What is your biggest worry of why you believe username , email, and date time needs to go in there? Are you allowing weak passwords and need other sources to make it more complex? Is this a very sensitive service no one should have account names listed and stored in the clear?

Where are you requirements coming from and what is your user base that you need this over the top hashing method?

# ? Mar 11, 2017 07:08

Hollow Talk: Feb 2, 2014

EVIL Gibson posted:

You should be focussing on difficulty and not mashing stuff together because you can.

Your N is only 16. Default scrypt N is 16384.

What is your biggest worry of why you believe username , email, and date time needs to go in there? Are you allowing weak passwords and need other sources to make it more complex? Is this a very sensitive service no one should have account names listed and stored in the clear?

Where are you requirements coming from and what is your user base that you need this over the top hashing method?

Aaaand that's why I probably shouldn't post code. Datetime etc. don't "go in there". The input for scrypt-input->hash is a byte-string (i.e. the password), and it also gets [length] random bytes from a system-dependent random source (in this case /dev/urandom) for the salt, then runs scrypt with them. It outputs a scrypt-hash, which is a dumb datastructure, which contains the values null, the hash and the salt. To check, it takes a scrypt-hash struct, which may contain whatever username (or null, or something else, because it does not matter at all, as you can see, because it doesn't ever call scrypt-hash-username) of which it extracts the hash (i.e. scrypt-hash-input) and the salt (i.e. scrypt-hash-salt), then runs scrypt over a given password with the stored salt, then compares the result with the stored hash (i.e. scrypt-hash-input) for equality. The result is a boolean. There is no "mashing together". The other struct is posted here because the other struct represents a full user entry, which is something that is useful in other places and which is used to update database entries etc., trying to show my original rationale for using separate tables for hashed passwords and hashed emails for sake of not having to cram the result of the first into the second, which is now moot.

Also, from the library wrapper used: "the overall difficulty N is given as exponent". That's 2^16.

So: username, email and datetime don't "go in there". It's not a sensitive service, quite the contrary, it's quite frivolous, which is why email hashing seemed like a decent idea because, ultimately, people are giving me their (at least to some extent) real email address so I can register a game character and let them reset passwords if they forget it and can't be bothered to just write to me so I can manually nuke their account so they can just re-register.

Hollow Talk fucked around with this message at 10:51 on Mar 11, 2017

# ? Mar 11, 2017 10:40

Absurd Alhazred: Mar 27, 2010; by Athanatos

https://twitter.com/preinheimer/status/841273046317060105

# ? Mar 14, 2017 07:37

Cup Runneth Over: Aug 8, 2009; She said life's
Too short to worry
Life's too long to wait
It's too short
Not to love everybody
Life's too long to hate

But how do you communicate a secure location for them to meet??

# ? Mar 14, 2017 07:58

Absurd Alhazred: Mar 27, 2010; by Athanatos

Cup Runneth Over posted:

But how do you communicate a secure location for them to meet??

The location doesn't have to be secure if they can just whisper sweet nothings into each others` ears.

# ? Mar 14, 2017 08:02

Cup Runneth Over: Aug 8, 2009; She said life's
Too short to worry
Life's too long to wait
It's too short
Not to love everybody
Life's too long to hate

Absurd Alhazred posted:

The location doesn't have to be secure if they can just whisper sweet nothings into each others` ears.

meanwhile, next door

# ? Mar 14, 2017 08:45

Absurd Alhazred: Mar 27, 2010; by Athanatos

Cup Runneth Over posted:

meanwhile, next door

פורים שמח!

# ? Mar 14, 2017 08:58

Kassad: Nov 12, 2005; It's about time.

I laughed.

# ? Mar 14, 2017 10:12

Loving Africa Chaps: Dec 3, 2007; We had not left it yet, but when I would wake in the night, I would lie, listening, homesick for it already.

Kassad posted:

I laughed.

lol

also a border guard would 100% just make them enter the password to erase the disk because that's the kind of people they are if you try and obstruct them in any way

# ? Mar 14, 2017 13:29

Cup Runneth Over: Aug 8, 2009; She said life's
Too short to worry
Life's too long to wait
It's too short
Not to love everybody
Life's too long to hate

It better take him to a blank screen where he has to type the real password unprompted to actually access his computer

# ? Mar 14, 2017 14:41

INTJ Mastermind: Dec 30, 2004; It's a radial!

VeraCrypt / TrueCrypt allow you to specify two passwords, one that unlocks a decoy partition and one that unlocks the hidden partition. Might be a good idea for hiding your kiddie porn / meth network contacts from the border patrol.

# ? Mar 14, 2017 17:34

andrew smash: Jun 26, 2006; smooth soul

I wonder if it's a hipaa violation if I'm required to unlock a device with patient info on it by border patrol

# ? Mar 14, 2017 19:53

Internet Explorer: Jun 1, 2005

It is. Have fun with that knowledge.

# ? Mar 14, 2017 19:57

Sickening: Jul 16, 2007; Black summer was the best summer.

andrew smash posted:

I wonder if it's a hipaa violation if I'm required to unlock a device with patient info on it by border patrol

Borders crossings in the US and US border patrol is a magical land of no constitution or laws. There is nothing to wonder. All sense of reality is suspended there.

# ? Mar 14, 2017 20:02

CLAM DOWN: Feb 13, 2007

Don't travel to/from the US hth

# ? Mar 14, 2017 20:03

some kinda jackal: Feb 25, 2003; �
�

My boss asked me which US security conference I wanted to attend this year and I just told her I'm not stepping foot across that border right now.

There's got to be something worthwhile in Europe ~~or Canada~~ instead.

# ? Mar 14, 2017 20:05

CLAM DOWN: Feb 13, 2007

Martytoof posted:

My boss asked me which US security conference I wanted to attend this year and I just told her I'm not stepping foot across that border right now.

There's got to be something worthwhile in Europe ~~or Canada~~ instead.

Same, I might go to one in the UK instead. Travel department is facing huge increase in travel cost but it's worth it.

# ? Mar 14, 2017 20:06

some kinda jackal: Feb 25, 2003; �
�

I think the most sensitive things on my devices are my mail caches, and even then that's just proprietary information, not CHD/PII or anything like that. The company could FedEx me my devices to a hotel in the states but that seems like a lot of effort to go through to not send me to Europe, or at least that's how I'm going to try to position it :haw:

# ? Mar 14, 2017 20:13

Adbot: ADBOT LOVES YOU

# ? Apr 27, 2024 22:32

Powered Descent: Jul 13, 2008; We haven't had that spirit here since 1969.

In this day and age, why would you physically carry super-secret information across the border at all? Fresh re-install the OS, fill the browser cache with a plausible amount of news sites, cat videos and Amazon window-shopping, then let the border people look at anything they want. When you get where you're going, just pull your heavily-encrypted files on the UFO people (or whatever) across the Internet from where you stashed them.

# ? Mar 14, 2017 20:33

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Infosec Thread: Yes, time to move off LastPass

«‹›504 »