|
dwazegek posted:While it's true that variables can be captured in a generated type, you'd also have to be capturing hundreds of variables before the class ends up in multi-kb territory. Which means that you have hundreds of variables in method scope to capture in the first place, which seems to be the real problem. I mostly use C# when writing for the Unity game engine, and they use iterators to implement coroutines, so while normally you'd keep iterators short, there it's pretty common to see functions that are hundreds of lines long doing some complicated game logic, interspersed with yields everywhere. Not saying any of this is necessarily bad tho, but it has performance implications you need to keep in mind when writing those kinds of applications. quote:However, I do wonder if C# is the right tool for your job if you frequently run into that sort of issue. Math heavy stuff has never really been one of C#'s strengths. I wish I had a choice in the matter, but see above  Unity also uses an ancient Mono compiler so until recently you couldn't even foreach on simple lists without generating garbage.
|
#
?
Jun 18, 2018 13:13
|
|
|
|
| # ? Jun 6, 2024 02:03 |
|
|
Well, there is a CLR language with compile-time generiticity  I assume it wouldn't work in Unity though.
|
|
#
?
Jun 18, 2018 14:47
|
|
|
LOOK I AM A TURTLE posted:Nice, this lets us get rid of even more entropy. I'll assume we have this keypad layout: Um... with both of the requirements, shouldn't the only possible combinations be variations of 135790? Which is 6! = 720 combinations out of 1000000 possible combinations for 6 digits (if we ditch both requirements), unless I've gotten my maths wrong. With diagonal adjacency, I don't see any codes where both requirements are met (at least for that keypad layout) edit: wait - is 137465 valid according to requirements? edit edit: vvv yup, reread it and it made sense, ty canis minor fucked around with this message at 15:19 on Jun 18, 2018 |
|
#
?
Jun 18, 2018 15:14
|
|
|
You're allowed to have numbers that are adjacent to other numbers. They just can't be adjacent to the immediately previous number. 162738 is fine.
|
|
#
?
Jun 18, 2018 15:17
|
|
|
Jabor posted:You're allowed to have numbers that are adjacent to other numbers. They just can't be adjacent to the immediately previous number. also 143685 is allowed its numerically adjacent not positional adjacent, so 01 12 23 34 45 56 67 78 89 and their inverses are not allowed neither is repeating a digit anywhere in the pin
|
|
#
?
Jun 19, 2018 10:42
|
|
|
Password strength requirements (which cannot be called that for reasons explained in this sentence) strictly reduce entropy and therefore security
|
|
#
?
Jun 19, 2018 22:47
|
|
|
xtal posted:Password strength requirements (which cannot be called that for reasons explained in this sentence) strictly reduce entropy and therefore security You say that, but if we didn't have them then millions of people would be using "password" and "123456" as their passwords. Of course, now they use "password!" and "abc123" instead. 
|
|
#
?
Jun 19, 2018 22:56
|
|
|
TooMuchAbstraction posted:You say that, but if we didn't have them then millions of people would be using "password" and "123456" as their passwords. Trustno1!
|
|
#
?
Jun 19, 2018 23:15
|
|
|
Just came across this as I'm breaking up a long function so I can cover it with tests:code:Now I'm trying to do code paleontology to figure out what used to be here that made this make sense. Edit: Also, this function is probably never passed a null value anyway. Whee! CPColin fucked around with this message at 05:48 on Jun 20, 2018 |
|
#
?
Jun 19, 2018 23:29
|
|
|
The answer to “how can this code possibly work when <thing> happens” does turn out to be “the callers just know not to use it like that” quite a lot. It’s usually a symptom of a technical management problem: an important piece of code doesn’t handle an important case correctly, but nobody feels empowered to fix it, so instead they just work around it in code they own. Leave it to fester long enough and the code will have a bad reputation, as if its bugs are somehow deeper and more intractable than bugs everywhere else. that code grows a reputation for being buggy and untrustworthy. You get these half-baked partial rewrites and wrapper libraries and piles of basically similar workarounds building up everywhere it’s used. Just ugliness breeding ugliness. ETA: now I think I’m talking about a pretty different class of problem than you actually posted, but whatever, I’ll leave this here.
|
|
#
?
Jun 20, 2018 01:31
|
|
|
https://en.wikipedia.org/wiki/Conway%27s_law
|
|
#
?
Jun 20, 2018 04:01
|
|
|
TooMuchAbstraction posted:You say that, but if we didn't have them then millions of people would be using "password" and "123456" as their passwords. I a lot of sites are now blocking "password" outright, in which case I suggest drowssap.
|
|
#
?
Jun 20, 2018 05:03
|
|
|
TooMuchAbstraction posted:You say that, but if we didn't have them then millions of people would be using "password" and "123456" as their passwords. I think it's dumb and ultimately a net loss to reduce everyone's security in order to increase a few idiots' security.
|
|
#
?
Jun 20, 2018 05:37
|
|
|
a hot gujju bhabhi posted:I think it's dumb and ultimately a net loss to reduce everyone's security in order to increase a few idiots' security. It's actually quite a few idiots. e: That said, I'd rather just blacklist the 1000 most common passwords than have stupid rules like "no repeating characters".
|
|
#
?
Jun 20, 2018 05:59
|
|
|
VikingofRock posted:It's actually quite a few idiots. That data says that 10% of people used the worst 25 passwords. So you're lowering the security for 100% of your users in order to increase it for 10% who knowingly and deliberately lowered their own security (and by the way depending on the rules you introduce, you may not even be increasing it enough to offset the decrease, in which case you've achieved nothing at all for any of your users).
|
|
#
?
Jun 20, 2018 06:14
|
|
|
there is no way to have a password system based upon causation and not have that pareto rule even the little puzzle lock things have a pareto rule of unlocking biometrics have a fuckin inequality in false positives it's not a whole bit of entropy if you do it right
|
|
#
?
Jun 20, 2018 06:27
|
|
|
bob dobbs is dead posted:there is no way to have a password system based upon causation and not have that pareto rule Exactly, you're just changing the 25 most commonly used passwords, you're not removing the fact that there will exist 25 passwords that are the most common. What are those 25 passwords? Take the same list SplashData used, filter out only the passwords that match your arbitrary rules and get the top 25 from that. You end up decreasing the overall set of possible passwords for no actual gain in security as far as I can tell. putin is a cunt fucked around with this message at 06:35 on Jun 20, 2018 |
|
#
?
Jun 20, 2018 06:32
|
|
|
Minimum password lengths reduce the total number of possible passwords, but people who are knowledgeable about passwords won't use short passwords anyway, so you're not reducing security by enforcing minimum lengths. Mixing different character types is also generally a good thing, and people who are knowledgeable are going to do that anyway, so again, no reduction in security. While it would be better if everyone in the world had a solid understanding of how to use passwords, that's also not reasonable to expect, so we use password rules to help those people. It only becomes an issue when the people who come up with the rules make bad decisions that prevent good passwords from being chosen, but the solution to that problem isn't to abolish the rules entirely.
|
|
#
?
Jun 20, 2018 06:42
|
|
|
Limit the most commonly used passwords and use their credentials to try and log into gmail to see if they're reusing passwords. If nothing else your sworn testimony in front of a Senate subcommittee will serve as a warning to people not to do that.
|
|
#
?
Jun 20, 2018 06:44
|
|
|
Do without passwords if you can. Find some other form of authentication. Please, I beg of you.
|
|
#
?
Jun 20, 2018 06:50
|
|
|
Recently used a service that enforced minimum 1 numeric, minimum 1 punctuation, minimum 8 characters total but maximum 10.
|
|
#
?
Jun 20, 2018 07:02
|
|
|
the current bind is that the adjacent characters are limited to just 1 rather than a more acceptable 2 or 3 12 is currently not allowed 123 should be the blocked one possibly or even allow that and block 1234 and again with the duplicate numbers - in a 6 digit pin allow 2 repeating would be more suitable so 112340 would be allowed or allow stuff like 110901 - 9-11 in UK order dd/mm/yy Dates and shaped are the usual pins for unlocking a phone, a phone with no access to corporate network and only access to the global addressbook and my emails, why so much protection for such a small device, PCs with access to the network are worse.... You must have min 8 characters and have at least one of each of the following, upper case, lower case, number, special character, not contain your username or password The password is changed every 6 months and you cannot repeat a password (or close to -ie mypasstouse1 mypasstouse2 etc) they have that set to 99 years. and you have to have a different password on the corporate network, the vpn, the website, any external system password managers are not allowed either without the requirement for the number and character it would be nice, there should be a new password rule min 8 characters and if the password is less than 15 characters the above rules apply otherwise no limits apply. so you could have S0methingAw£ful or you could do correct horse battery staple
|
|
#
?
Jun 20, 2018 07:04
|
|
|
a hot gujju bhabhi posted:Exactly, you're just changing the 25 most commonly used passwords, you're not removing the fact that there will exist 25 passwords that are the most common. What are those 25 passwords? Take the same list SplashData used, filter out only the passwords that match your arbitrary rules and get the top 25 from that. the overall set of possible passwords is dominated by good passwords this is like saying that caches are useless because you still have to do computation and if you take the 25 most common requests and cache them, there will still be a 25 most common uncached set of requests. long computation here = poo poo password
|
|
#
?
Jun 20, 2018 07:14
|
|
|
TheresaJayne posted:
I'd stick with variations of C4Ntwa1tfor4newj0b!, tH1s"j0b"sucks etc. If login security is so important, why no 2FA? It seems like someone near the top has decided "security is super important" but they don't know of any security beyond passwords.
|
|
#
?
Jun 20, 2018 08:14
|
|
|
TheresaJayne posted:The password is changed every 6 months and you cannot repeat a password (or close to -ie mypasstouse1 mypasstouse2 etc) they have that set to 99 years. Systems that do this are extra cool because it means they are storing the passwords in a way that makes it possible, probably trivial, to retrieve the actual plaintext of the passwords  Edit: Or at best some description of your password that can surely be used to reduce the time it would take to crack it. But let's face it, they're definitely stored as text. Mooey Cow fucked around with this message at 12:24 on Jun 20, 2018 |
|
#
?
Jun 20, 2018 12:11
|
|
|
Mooey Cow posted:Systems that do this are extra cool because it means they are storing the passwords in a way that makes it possible, probably trivial, to retrieve the actual plaintext of the passwords No they aren’t. When you change your password, the old one is kept to do these checks, but the current one is never stored insecurely. The tests to make sure it’s not “too similar” can be done client side by knowing the old passwords and the one you’re trying to change it to without transmitting anything insecurely. This is a common feature in a lot of authentication systems like Active Directory.
|
|
#
?
Jun 20, 2018 13:56
|
|
|
Mooey Cow posted:Systems that do this are extra cool because it means they are storing the passwords in a way that makes it possible, probably trivial, to retrieve the actual plaintext of the passwords generally passwords aren't stored, password hashes are, So when you enter the password, it gets hashed using such an algorithm, and the hash is compared, not the actual plaintext. There isn't a simple way of turning a hash into a password because the hash itself doesn't contain enough information by itself for you to get the password, and utilities that try to crack passwords will generally just try every single combination of letters/numbers until you find a password that matches. If you have rainbow tables (e.g. a dictionary of common passwords -> password hashes for a given algorithm), you can just use the tables to look up the password from the hash - the counter-measure to this is having a 'salt' value in the hash (e.g. instead of just hashing the password, hash the password plus a 'salt' value stored in the database.) In the 90's md5 and sh1 + salt was OK for security, but computers have gotten really fast - it's possible to brute force (try every password and see what its hash is) over 3 million passwords a second against md5, for instance. But just knowing the hash of the last few passwords stored is no more insecure that the login process itself, given the use of an algorithm like bcrypt to generate hashes.
|
|
#
?
Jun 20, 2018 14:13
|
|
|
Bruegels Fuckbooks posted:generally passwords aren't stored, password hashes are, So when you enter the password, it gets hashed using such an algorithm, and the hash is compared, not the actual plaintext. There isn't a simple way of turning a hash into a password because the hash itself doesn't contain enough information by itself for you to get the password, and utilities that try to crack passwords will generally just try every single combination of letters/numbers until you find a password that matches. How do you tell that two passwords are similar based on their hashes?
|
|
#
?
Jun 20, 2018 14:29
|
|
|
Dr. Stab posted:How do you tell that two passwords are similar based on their hashes? You don't. You make the user enter their old password when they're changing it to a new one so the comparison can be done client-side.
|
|
#
?
Jun 20, 2018 14:36
|
|
|
If you're checking that a password is the same as previous passwords, you just hash it using the same parameters as the previous passwords and see if it matches, then store however many previous hashes are needed for whatever security policy. With proper bcrypt parameters the old passwords should be mostly useless to an attacker anyhow.
|
|
#
?
Jun 20, 2018 14:56
|
|
|
The example given was that if you had "mypasstouse1" previously you couldn't choose "mypasstouse2" E: storing old passwords in the clear is only a small step above storing present passwords in the clear. You're assuming your dissimilarity metric will cause users to create unique, secure passwords everytime. That's not a very reasonable assumption. Dr. Stab fucked around with this message at 15:12 on Jun 20, 2018 |
|
#
?
Jun 20, 2018 15:07
|
|
|
The example was that you couldn't repeat a password or use a similar one for 99 years. The only way you can check similarity that far back is by allowing your system to reconstitute the plain-text passwords. What teamdest and Jethro are talking about only works for verifying that your new password doesn't match your current password.
|
|
#
?
Jun 20, 2018 15:13
|
|
|
While I guess the whole point of this thread is that no one deserves the benefit of the doubt, I would hope that the system is actually "You can't reuse passwords ever (because we store the hashes for all your old passwords) and you can't use a password that is too similar to your current one (because we compare them before we compute and save the hash)."
|
|
#
?
Jun 20, 2018 15:25
|
|
|
I liked the system we had for a bit a couple jobs ago where you had to use a password with lower-case, upper-case, numbers, and symbols, but if you were over 12 characters or so, you needed only three of those, over 16 and you needed only two of those. That way, it primarily encouraged longer passwords. They ditched that system when they switched to Active Directory. Meanwhile, at my current job, also on AD, I discovered one day that I couldn't connect to any of the network shares, because my password had expired. I use Linux, so there was nothing to notify me of that fact or let me change it. I had to fire up my Windows VM in order to add the requisite "1" to my password.
|
|
#
?
Jun 20, 2018 15:40
|
|
|
Jethro posted:While I guess the whole point of this thread is that no one deserves the benefit of the doubt, I would hope that the system is actually "You can't reuse passwords ever (because we store the hashes for all your old passwords) and you can't use a password that is too similar to your current one (because we compare them before we compute and save the hash)." One would hope so, but consider how many times we've heard that millions passwords are now compromised because some site got hacked and turns out they didn't even hash the passwords... I've had to use systems in the past that required your new passwords to be dissimilar from your current as well as any previous passwords, so they were definitely storing something more than just hashes. It'd be nice if all sites and whatever could be open with how they handle secret information. But hey, at least we have a law that requires them to say if they use cookies
|
|
#
?
Jun 20, 2018 15:45
|
|
|
I once saw a site the encrypted the passwords with base64
|
|
#
?
Jun 20, 2018 15:58
|
|
|
For checking whether any close numerical relatives exist for a given password, perform the transformations before hashing it. So if there’s a number on the end try decrementing it by one and test that instead of storing and transforming the old password. It’s not robust but it’ll catch the worst password patterns.
|
|
#
?
Jun 20, 2018 16:25
|
|
|
Facebook apparently uses a method where they store hashes of various common permutations of your passwords and then compares against all of them for a similarity check, and people are recommending others to also do this if they want that kind of functionality. But seems to me that 1) that'll take up a lot of space and 2) that you'll give an attacker a big box of near hits and an algorithm that can probably generate the full set of possibilities that will contain the real password from a single near hit. Maybe not though, or maybe they think it's worth it 
|
|
#
?
Jun 20, 2018 16:40
|
|
|
Mooey Cow posted:Facebook apparently uses a method where they store hashes of various common permutations of your passwords and then compares against all of them for a similarity check, and people are recommending others to also do this if they want that kind of functionality. But seems to me that 1) that'll take up a lot of space and 2) that you'll give an attacker a big box of near hits and an algorithm that can probably generate the full set of possibilities that will contain the real password from a single near hit. Maybe not though, or maybe they think it's worth it Let's say that a password hash is 128bit / 16 bytes and that there are 10k "common permutations" for each password. That's an extra 156kB of storage per user. Nontrivial, maybe, but not remotely close to the storage dedicated for all the poo poo the user's doing with your system. You also don't tell the user that their password is too close to an old password unless they've also provided their current password as part of the transaction. So the attacker would need to already have access to their current password in order to gain any information.
|
|
#
?
Jun 20, 2018 16:46
|
|
|
|
| # ? Jun 6, 2024 02:03 |
|
|
Have I been pwned has an API. Isn’t that sufficient?
|
|
#
?
Jun 20, 2018 17:02
|
|
