Results 31 to 51 of 51
-
2022-07-01, 10:15 AM (ISO 8601)
- Join Date
- Mar 2005
- Location
- 61.2° N, 149.9° W
- Gender
Re: A question about password security
-
2022-07-01, 11:15 AM (ISO 8601)
- Join Date
- Aug 2010
Re: A question about password security
True.
However, knowing how this stuff works at a fairly basic level can give end users a reasonable understanding of what attacks are possible, and what they need to protect against - and, as part of that, "why password complexity requirements matter", the point of the OP.
Which basically means that the info is still stored in the database in the form of the row id. How that's turned into the salt is obscured, but security through obscurity isn't. It may add a tiny tiny layer of additional difficulty, but again knowing the salt doesn't give you the password, and that's not the problem salt solves."Gosh 2D8HP, you are so very correct (and also good looking)"
-
2022-07-01, 11:35 AM (ISO 8601)
- Join Date
- Jul 2004
- Location
- Freiburg, germany
- Gender
Re: A question about password security
Oh, absolutely. it's always good to have at least a basic understanding of what's going on. The point I was trying to make is: don't trust the other side to keep your data secure, don't trust a third party (online passwordsafes for example). try to make everything as secure as YOU can and don't worry too much about stuff you have no influence over. Encrypt data stored in the cloud and use 2FA where possible. that way reasonably secure password are enough. no need to go for 16 word sentences with random substitutions or something like that.
Also: if you really want to use different secure passwords on every site, make sure you personally can reproduce them. basic example (not too secure, mind) "site.domain.tld+momsbirthday" and run that through a reversible hash yourself. that way you can recover the random BS password on any system that can run your hash. by itself, that's not too good, but coupled with a second factor it's usually more than enough and mostly alleviates the need for a password safe.
-
2022-07-01, 11:38 PM (ISO 8601)
- Join Date
- Mar 2005
- Location
- 61.2° N, 149.9° W
- Gender
Re: A question about password security
Well its calculated from a standard db value, probably a hash itself. You'd need to dig into bespoke source code to find the actual methods. The person I spoke to was also rather... salty... about standard salting. Theres some other intermediate step before the final hashes & storage of name & pass. I'm willing to believe the person that the usual first pass scripts & attempts will still return gibberish. Wouldn't put it past that person to build in honeypot logins into the db too.
Personally I always wondered why biometric 2fa hasn't taken off. I know several chaps who have the password locker on their phone, that's used for their 2fa too.
-
2022-07-02, 05:50 AM (ISO 8601)
- Join Date
- Jul 2004
- Location
- Freiburg, germany
- Gender
Re: A question about password security
1. because your biometrics can't be changed on loss or breaches
2. because 2fa still needs to be somehow stored on the server side, which isn't exactly trustworthy (see my previous rant).
2.a because some biometris are comparatively easy to forge, and they would then be in a breach of server side credentials
2.b exception would be if you generated the 2fa code on your device, in which case it's just needlessly complicated
3. because you'd have to trust some devices manufacturer with biometric data, who themselves are not really trustworthy
counterpoint: what problem would biometric 2fa solve as opposed to traditional TOTP 2fa for example? other than "my fingers are always with me"?
-
2022-07-02, 05:35 PM (ISO 8601)
- Join Date
- Mar 2005
- Location
- 61.2° N, 149.9° W
- Gender
Re: A question about password security
Sorry, was posting late at night and I wasn't very clear. I meant using biometrics to generate a pseudo password and then 2fa the password back to the encoding device where the biometric gets run again. My concern is these systems I see with the login & phone stored in the db where the 2fa consists of just answering the phone or a pin sent to the phone. The main issue being a stolen phone turns into the whole login from a bookmarked site, the saved password, and the 2fa id. So not the issues at the stolen db level.
Also, TOPT? De-acryonim?
-
2022-07-02, 06:56 PM (ISO 8601)
- Join Date
- Mar 2007
- Location
- Oregon, USA
Re: A question about password security
The primary thing there is that having the password saved on the same phone in such a readily usable fashion effectively reduces things to one-factor authentication; the value of the second factor is verifying you have access to the associated phone independent of having access to the password (the first factor), and the password being saved on the phone means they're no longer independent.
Anyway, using biometrics has problems of its own. In addition to the issues Whoracle already mentioned, a key one is that the body is not a static thing....Just to throw out an example, I am rather certain that I would fail retina scans after my retina detachment last year; and reasonably certain that it results will have changed even after I've fully recovered from the reattachment surgery it. Admittedly an extreme case, but the point is that scenarios like this, however mild, are going to be far more onerous for anyone trying to legitimately use biometrics than for anyone trying to break them; and that's not likely to promote widespread adoption.
So this is basically comparing "don't suffer bodily accidents" vs "don't save your password on the same phone"; the latter is far more controllable.
Time-based One Time Password, including stuff like the "pin sent to the phone" thing you mentioned.FeytouchedBanana eldritch disciple avatar by...me!
The Index of the Giant's Comments VI―Making Dogma from Zapped Bananas
-
2022-07-02, 08:10 PM (ISO 8601)
- Join Date
- Mar 2005
- Location
- 61.2° N, 149.9° W
- Gender
Re: A question about password security
Yes, precisely what I dislike, everything on one phone is (on the user end) basically shooting any 2fa scheme dead. Its also tremendously common because of saved passwords & that phone being the second factor.
I would be interested to see a scheme that used the biometrics on the second step of 2fa. Instead of the pin, timed code, answering the phone stuff. I don't feel that loss of one biometric is any different from a recovery point of view than resetting a forgotten password. My phone has three different fingers registered, although thats more about me doing weird positions sometimes than from any lost finger worries.
-
2022-07-03, 12:46 AM (ISO 8601)
- Join Date
- Sep 2011
- Location
- Calgary, AB
- Gender
Re: A question about password security
Okay, but, those are all things that can be generated at the time of use. That means they can be used to do things like "Prove that you have access to the user's phone," which is what 2FA means. Like, not only do you know the basic stuff like username and password, but you also have the phone of said user, increasing the odds that you actually are said user.
Biometrics are going to necessarily be something you've set up in advance; it's not like they send you new fingers to scan in with when you request a change or whatever. And if you haven't pre-registered your biometrics, then they have no way of matching it to you in the first place. That functionally makes it just another password. That is, "Do you have this person's biometric data" is just a fancy way of asking "do you have this person's secondary password."
-
2022-07-03, 02:43 AM (ISO 8601)
- Join Date
- Jul 2004
- Location
- Freiburg, germany
- Gender
Re: A question about password security
Finally on my PC instead of on the phone, so maybe my ramblings will make a bit more sense now
Right, I forgot that people actually use their phones as their main internet-capable device. That's on me. Yeah, if you use your phone you don't want to have your 2nd factor stored on that. That's where hardware tokens like the aforementioned yubikey come in. Use one of those.
But still - if you store your password and username, that's on you - first off you're handing out the first (or rather the first two, since technically the username is also a factor and 2FA is really 3FA) factors, you've artificially weakened your security. More convenient, sure, but convenience and security are antithetical, sadly.
Originally Posted by Telok
Exactly.
Originally Posted by Jasdoif
This talks about how easily one can fool most high-end consumer iris scanners and facial recognition software. tl;dw: It could be done with magazine photos.
Granted, this was 8 years ago, and the tech has most likely gotten way better, but do you want to bet that a given service provider has actually implemented the better versions?
Edit: Here's a short demonstration from 2017 how the same guy defeated a newer version of the iris scan: https://media.ccc.de/v/biometrie-s8-iris-en /End Edit
There was a similar talk with fingerprint readers a few years earlier (even with "is this person alive" detection, but I can't find an english translation right now.
Again: Hardware tokens. If someone stores everything on the same device, there's sadly no helping that person. The fact that they store their password alone means that the topic of this thread is kind of moot: NO matter how complex your password and no matter how good the server-side implementation, and no matter how many factors: If you store that stuff, all that becomes one factor (as Jasdoif said) - "I possess the phone". Might as well go with 12345 at that point, really.
Originally Posted by Telok
tl;dr: Don't use the same device for everything. A second factor needs to be distinct from wherever you keep your first factor. Use hardware tokens.
Of course, the whole discussion is kind of moot, since most service providers STILL don't even implement "We're mailing you a 4-digit code" 2FA, let alone TOTP, Biometrics, or anything else. It's getting better, slowly, but who wants to bet how many decades it'll take for these forums for example to implement 2FA? They don't have staff on hand that has both the time and know-how to implement (and, more crucially, support) that kind of stuff, and even if they had, I doubt they'd be willing to bolt that onto whatever version of vBulletin runs under the hood here.Last edited by Whoracle; 2022-07-03 at 02:45 AM.
-
2022-07-03, 07:39 AM (ISO 8601)
- Join Date
- May 2007
- Location
- The Land of Cleves
- Gender
Re: A question about password security
I think the point of biometric factors is that, in the typical use case, most other two-factor schemes offer no extra security at all: If my phone is my primary or even only online device, and someone steals my phone, they have my everything. The phone is a single factor. But even if they steal my phone, they didn't steal my finger or my face or whatever. Sure, maybe it's easy to fake a fingerprint, which makes that a weak second factor, but it's not completely free, and a weak second factor is better than no second factor at all. And maybe you can combine multiple biometrics into something that's more acceptably secure: It doesn't take the same kind of effort to steal a fingerprint, a face, and a voiceprint, so it's more difficult to steal all three.
Time travels in divers paces with divers persons.
As You Like It, III:ii:328
Chronos's Unalliterative Skillmonkey Guide
Current Homebrew: 5th edition psionics
-
2022-07-03, 02:53 PM (ISO 8601)
- Join Date
- Mar 2005
- Location
- 61.2° N, 149.9° W
- Gender
Re: A question about password security
Yeah, OK. Don't bother. I don't seem to be able to explain what I'm talking about well enough to be understood. Maybe I'll pencil out an actual flowchart of try and figure out a better explanations.
-
2022-07-03, 04:04 PM (ISO 8601)
- Join Date
- May 2009
Re: A question about password security
It could significantly improve its security right now, today, by simply deleting the cookie that automatically logs me in when I navigate here. I'm guessing the reason it doesn't is that, for a forum like this, ease of use is much, much more important than security.
After all, there's no financial information here, there's no personally identifiable information, no medical or personal information of any sort, at least not in any structured form. As targets go, it's about as low value as you could find.
I can see a danger from password reuse, but is there anything else?"None of us likes to be hated, none of us likes to be shunned. A natural result of these conditions is, that we consciously or unconsciously pay more attention to tuning our opinions to our neighbors pitch and preserving his approval than we do to examining the opinions searchingly and seeing to it that they are right and sound." - Mark Twain
-
2022-07-03, 05:36 PM (ISO 8601)
- Join Date
- Feb 2016
Re: A question about password security
Precisely, and exactly the same goes for most of the sites with these crazy password requirements. Over the years I've encountered my sites that are casual sites similar to this one but for some reason have far more stringent password requirements than most of the programs I use that actually have a reason to need to be secure; I've been on forums and art sites that for some reason have significantly more stringent password requirements than my mobile banking app or logging into the network at my job at the drug store.
Last edited by Bohandas; 2022-07-03 at 05:39 PM.
"If you want to understand biology don't think about vibrant throbbing gels and oozes, think about information technology" -Richard Dawkins
Omegaupdate Forum
WoTC Forums Archive + Indexing Projext
PostImage, a free and sensible alternative to Photobucket
Temple+ Modding Project for Atari's Temple of Elemental Evil
Morrus' RPG Forum (EN World v2)
-
2022-07-04, 03:04 AM (ISO 8601)
- Join Date
- Mar 2007
- Location
- Oregon, USA
Re: A question about password security
Well, if you'll bear with me for a moment while I get into the weeds (which don't appear to have advanced significantly since the last time I looked into this)....
Multiple readings of the same fingerprint do vary. Due to things like applied pressure, temperature, skin condition, exact angle of the finger, etc. affecting the scan. But whatever the exact reasons, today's fingerprint verification still works by building a numeric model representing of the key patterns in the scan and their spatial relationships, comparing that against a model built from a known scan of the fingerprint in question, and deciding if the two are close to have been from the same fingerprint; building on the foundation of decades of fingerprint forensics.
This is critically relevant here for two particular reasons:
- There is not a singular canonical form of a fingerprint; scans at different times and/or from different devices will be different, and nothing innately says one is "truer". The closest you can get is for a system to choose a particular scan as authoritative, and all others measured by how closely they compare to it.
- To do that comparison, both the model being tested and the model being compared against must be available; which means that (unlike with a password) a hash isn't adequate here since the whole idea is predicated on not needing to keep the thing being hashed.
The latter point warrants a little more commentary....A database for validating scans of user-registered fingerprints has to include those fingerprint patterns. And the main reason fingerprinting has been in use for identification for over a century is that fingerprints don't change outside of extreme situations; even after being burned off (literally or caustically), the skin will eventually regrow the same fingerprint pattern it had before. The data to falsify a fingerprint must be present in the system intended to validate it, and a stolen fingerprint pattern continues to be valid for the original person for the remainder of their life, no matter who's using it.
That a fingerprint also has a distinctive irrevocable association with a person in physical space also raises some issues...including the mundane fact that a phone operated by hand will have the operator's fingerprints on it; a stolen phone could have extractable fingerprints without recourse to digital wizardry or what have you.
Okay, onto what I think your scenario was...Unless/Until the technical hurdles above are solved:
- Using fingerprint scans to fill a password field (say, the hash of a consistently structured digital model or something) doesn't work because there's no single innate form of the fingerprint; each scan would produce a different result, and naturally you'd need the passwords to match. Saving a single scan of the fingerprint, and using that when provided a scan close enough, could possibly work...but then you're still saving the scan on the device; and honestly, since you can't use this elsewhere without moving a copy of the scan/model around you're not getting more out of it than you would with a conventional password.
- What (I think) you're talking about is very similar to push authentication (you hit a button on the login page, an app on your phone pops up a notification saying "hey was that you trying to log in?", you tell it "yes that was me trying to log in", logging in continues on its merry way); you've just got an intermediate step of requiring a scan. If the issues above don't faze you (a big if), I don't see why a protocol couldn't involve sending a one-time HMAC key to use in the response as sort of a digital signature of the object representing the biometric scan/model.
tl;dr The technology current used to identify fingerprints isn't advanced enough to treat them the same way as passwords, and the same properties that make fingerprints convenient for identity use also make them convenient for identity abuse in the digital realm.FeytouchedBanana eldritch disciple avatar by...me!
The Index of the Giant's Comments VI―Making Dogma from Zapped Bananas
-
2022-07-04, 03:35 AM (ISO 8601)
- Join Date
- Mar 2005
- Location
- 61.2° N, 149.9° W
- Gender
Re: A question about password security
Yeah, see, I wasn't thinking of using the fingerprint as a "password" itself. Biggest issue is these days I rarely get open time during the day, so its either fast typing or type half a sentence at a time every 10-15 min until done or not do one of my things on the 1-3 times a week I can do my stuff.
I am aware of the limits of consumer electronics biometric sensors. I haven't been trying to say replace passwords with, or store a specific biometric on a server for id. But work it into the authentication as an enhacment of the current system to alleviate some of the issues surrounding passwords, password managers, and everything-on-one-phone. I am aware that a dedicated professional can bypass basically anything given time and no responses. But steps folded into the current security flow, with low user overhead, that improve some of the main problems average users cause for security... and I'm just have trouble... getting out a coherent vision of a sketched out idea.
-
2022-07-04, 10:32 AM (ISO 8601)
- Join Date
- May 2007
- Location
- Tail of the Bellcurve
- Gender
Re: A question about password security
I've never wanted a fingerprint login system because my hobbies involve knives, chisels, blowtorches and very hot pieces of metal. So while most days I have normal fingerprints, every now and again one or more fingers gets seriously modified - as in I slice a piece off and it goes flying across the room.
Blood-red were his spurs i' the golden noon; wine-red was his velvet coat,
When they shot him down on the highway,
Down like a dog on the highway,And he lay in his blood on the highway, with the bunch of lace at his throat.
Alfred Noyes, The Highwayman, 1906.
-
2022-07-04, 11:12 AM (ISO 8601)
- Join Date
- Jan 2007
Re: A question about password security
To be honest, this casual attitude toward hand injury kind of reminds me of this UHF scene.
In a war it doesn't matter who's right, only who's left.
-
2022-07-04, 02:03 PM (ISO 8601)
- Join Date
- Aug 2011
Re: A question about password security
The way my phone works is that it requires a password every so often, but allows fingerprints in between passwords to act as authentication. This feels like a reasonable speed-of-use middle ground since, if I had my phone 15 minutes ago, I probably still have my phone, but if I'm just powering up the phone or if it's been a while since I typed in a password, it locks up until I can give it the password.
I can imagine a similar system where you're allowed a 15 minute window to (re)supply a finger print to keep working with whatever protected system you're working with, but on initial login/after long breaks you're required to type in a long, secure password (ideally randomly generated from a password manager). This is basically how my online banking works, except they don't require a finger print to do anything, it just gives me a 15 minutes time window and as long as I'm active it assumes it's me.
The upside would be speed of use (plopping a digit down on a scanner is faster than passwords and TOTP) and your finger prints are more closely tied to you as a person (TOTP/password managers really check if you have access to a particular device, which could well be multiple people if, say, your husband or wife has access to your phone). The downside is that fingerprints are generally less secure than passwords, and really aren't modifiable in the case of a breach. It's maybe the kinda thing you only allow in house on secure networks; you don't store the prints in a database, you rescan them at the start of the day when the user first logs in and they're gone after 8 or so hours.Originally Posted by crayzzOriginally Posted by jere7my
-
2022-07-05, 11:49 AM (ISO 8601)
- Join Date
- Oct 2016
Re: A question about password security
Your intuition is wrong, the comic assumes the attacker knows the scheme, and that does not change by more people using it.
And worse: your math is also wrong.nope mine is
XKCD uses a dictionary of 2048 words which is the 44 bits of entropy mentioned in the fifth panel. ( 2048^4 = 2^11^4 = 2^44 = 44 bits). This may be a reference to BIP39 which uses a 2048 word dictionary to translate 256 bit long ed25519 private keys to 24 word phrases. (however two of the words the comic uses are not in the mnemonic word list proposed by BIP39)
Anyway 2^44 is roughly 1.75e13 and that is strictly larger than 100^8 aka 1.0e9, by a factor of over 1000. This is were your math is wrong. You need to pick 14 times from a set of 100 to beat the xkcd scheme, not 8 times.dammit ^^ see post below
nope 100^8 is as good as 10^16 see post below
What your intuition hides is that 8 out of 100 is just as good as picking 9 from a set of 10. All those special characters, upper- and lowercase that are needed to have 100 characters available - they have the same effect as using one more number in a purely numeric password: The password Kö}y%4B is exactly as secure as 674816733 under the assumption that the attacker knows the password scheme.
The whole point of asking people to use special chars is because if we say "use 8 letters at random" they don't pick a password like "skfiqwpu" they use literally "password" which is 8 letters but not very random at all.
However there is a valid problem with the XKCD proposal that the comic doesn't address: it requires people to choose randomly for its stated entropy and if people choose intuitively, we get the same problem of simplified schemes again. So the scheme falls for the same problem it criticizes: people are likely to pick more common words more often or use simplified schemes like "object-verb-attribute-object" with each group being much smaller than 2048.
For people to pick truly randomly from a large set, like 100 characters or 2048 words, they require tool assistance. And if we use tooling, then we could as well pick 256 times from the set {0, 1}. Like for example with an ed25519 private key. Such a binary key can be translated onto a set of 2048 words to become a 24 word passphrase. It is also equivalent to roughly7839 characters from a set of 100 characters.
Now here is the real funny thing: all the words in the BIP39 english mnemonic wordlist have 4 distinct starting letters. So if the attacker knows the scheme, then "CorrectHorseBatteryStaple" is equivalent to "corrhorsbattstap" - all those extra letters and case differences , they are just there for humans to remember it easier. The entropy is still 44 bits and that is roughly equivalent to picking137 from 100 hard to remember special characters.
Imho randomness is the second most important thing. The most important thing is keeping the password a secret, which implies not reusing it. That is the most important because the biggest problem is not entropy and brute forcing, but password reuse: https://xkcd.com/792/Last edited by Lo'Tek; 2022-07-05 at 04:13 PM. Reason: See post below
-
2022-07-05, 12:59 PM (ISO 8601)
- Join Date
- Aug 2011
Re: A question about password security
100^8 is 1e16, not 1e9, and is substantially larger than ~2e13. The actual error (as you describe) is thinking people are at all random about their 8 character strings: they aren't, they take words and make common substitutions and modifications. Effectively, your options for passwords people can actually generate on the spot and remember are "pick a word and make some modifications to it" (about 10-12 bits of security plus maybe another 20 if they're unusually good about making lots of modifications) or pick a handful of common words, which sits north of 40 bits of security even assuming a small (2000 word) dictionary they're choosing from.
EDIT
I just checked rockyou.txt, and variations of my usual passwords appear in there, so in my case I'm sitting at, at best, 30 bits of security assuming the data breach features properly salted passwords, which isn't a safe assumption.Last edited by crayzz; 2022-07-05 at 01:04 PM.
Originally Posted by crayzzOriginally Posted by jere7my