|
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 |
|
|
# ? Apr 27, 2024 20:41 |
|
OSI bean dip posted:Or that the smart TV nonsense requires physical access too. I'm cool with any FUD about smart TVs because they loving suck anyways.
|
# ? Mar 9, 2017 19:10 |
|
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 |
|
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 |
|
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 |
|
https://twitter.com/Bugcrowd/status/839884929840386048 1Password is putting its money where its mouth is.
|
# ? Mar 9, 2017 21:04 |
|
Modest Mouse cover band posted:How's this guide for password generation and storing? 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 |
|
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. Oh very cool, that will work perfectly. Thanks.
|
# ? Mar 9, 2017 22:20 |
|
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. 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 |
|
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. 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 |
|
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. 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 |
|
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. 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 |
|
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. Hollow Talk fucked around with this message at 23:28 on Mar 10, 2017 |
# ? Mar 10, 2017 22:42 |
|
I realise I'm not addressing your question but you don't need two tables for that
|
# ? Mar 10, 2017 23:19 |
|
when you get compromised how are you informing your potential userbase
|
# ? Mar 11, 2017 00:31 |
|
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 |
|
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 |
|
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 |
|
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:
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. 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 |
|
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 |
|
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 Whoops, I forgot the function that generates the hash in the first place. 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 |
|
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. 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 |
|
EVIL Gibson posted:You should be focussing on difficulty and not mashing stuff together because you can. 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 |
|
https://twitter.com/preinheimer/status/841273046317060105
|
# ? Mar 14, 2017 07:37 |
|
But how do you communicate a secure location for them to meet??
|
# ? Mar 14, 2017 07:58 |
|
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 |
|
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 |
|
Cup Runneth Over posted:meanwhile, next door פורים שמח!
|
# ? Mar 14, 2017 08:58 |
|
I laughed.
|
# ? Mar 14, 2017 10:12 |
|
Kassad posted:
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 |
|
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 |
|
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 |
|
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 |
|
It is. Have fun with that knowledge.
|
# ? Mar 14, 2017 19:57 |
|
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 |
|
Don't travel to/from the US hth
|
# ? Mar 14, 2017 20:03 |
|
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
|
# ? Mar 14, 2017 20:05 |
|
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. 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 |
|
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
|
# ? Mar 14, 2017 20:13 |
|
|
# ? Apr 27, 2024 20:41 |
|
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 |