Did you know that anyone, anywhere in the world can get into a gmail account merely by knowing its creation date (month and year is sufficient) and the last login date (try "today")? What a joke. Try it by yourself, its "fun". Even worse, once the attacker had control of your account once, and you reset the PW and then enable 2-factor-authentication, he will always come back because it is sufficient for him to know one of the last passwords to reset it again. This will totally work around 2-factor-authentication and allows him to remove/change recovery E-Mail + phone + turn off 2FA. There's no way to get rid of him. What a mess! I have a gmail account that mostly sends mail and barely receives any. This is probably why it works so damn easy. Otherwise the PW recovery process will ask you for the E-Mail addresses of people that you have received mail from in the past. But even this can get easily guessed/researched.
On (2015-05-26 16:26 +0200), Markus wrote: Hey,
Did you know that anyone, anywhere in the world can get into a gmail account merely by knowing its creation date (month and year is sufficient) and the
Without any comment on what gmail is or is not doing, the topic interests me. How should recovery be done in scalable manner? Almost invariably when the accounts were initially created there is no strong authentication used, how would, even in theory, it be possible to reauthenticate strongly after password was lost? One solution is, that you can opt-out from any password recovery process, which also would mean opt-in for deletion of dormant accounts (no login for 2 years, candidate for deletion?). I personally would opt-in for this in every service I have. I recall gandi allows you to disable password recovery. Perhaps some people would trust, if they could opt-in for reauthentication via some legal entity procuring such services. Then during account creation, you'd need to go through same authentication phase, perhaps tied to nationalID or comparable. This might be reasonable, most people probably already trust one of these for much more important authentication than email, but supporting all of them globally seems like very expensive proposal. -- ++ytti
On May 26, 2015, at 5:22 PM, Saku Ytti <saku@ytti.fi> wrote:
On (2015-05-26 16:26 +0200), Markus wrote:
Hey,
Did you know that anyone, anywhere in the world can get into a gmail account merely by knowing its creation date (month and year is sufficient) and the
Without any comment on what gmail is or is not doing, the topic interests me.
How should recovery be done in scalable manner? Almost invariably when the accounts were initially created there is no strong authentication used, how would, even in theory, it be possible to reauthenticate strongly after password was lost?
I think opt-out of password recovery choices on a line-item basis is not a bad concept. For example, I’d want to opt out of recovery with account creation date. If anyone knows the date my gmail account was created, they most certainly aren’t me. OTOH, recovery by receiving a token at a previously registered alternate email address seems relatively secure to me and I wouldn’t want to opt out of that. Recovery by SMS to a previously registered phone likewise seems reasonably secure and I wouldn’t want to opt out of that, either. Recovery by SMS to a phone number provided with the recovery request I would most certainly want to disable. (yes, some sites do this). Recovery by having my password plain-text emailed to me at my alternate address (or worse, an address I supply at the time of recovery request), not so much. (yes, many sites actually do this) Really, you don’t need to strongly authenticate a particular person for these accounts. You need, instead, to authenticate that the person attempting recovery is reasonably likely to be the person who set up the account originally, whether or not they are who they claimed to be at that time.
Perhaps some people would trust, if they could opt-in for reauthentication via some legal entity procuring such services. Then during account creation, you'd need to go through same authentication phase, perhaps tied to nationalID or comparable. This might be reasonable, most people probably already trust one of these for much more important authentication than email, but supporting all of them globally seems like very expensive proposal.
This also would take away from the benefits of having some level of anonymity in the account creation process, so I think this isn’t such a great idea on multiple levels. YMMV. Owen
Haha I cringe when I do a password recovery at a site and they either email the current pw to me in plain text or just as bad reset it then email it in plain text. Its really sad that stuff this bad is still so common. On Tue, May 26, 2015 at 11:44 AM, Owen DeLong <owen@delong.com> wrote:
On May 26, 2015, at 5:22 PM, Saku Ytti <saku@ytti.fi> wrote:
On (2015-05-26 16:26 +0200), Markus wrote:
Hey,
Did you know that anyone, anywhere in the world can get into a gmail account merely by knowing its creation date (month and year is sufficient) and the
Without any comment on what gmail is or is not doing, the topic interests me.
How should recovery be done in scalable manner? Almost invariably when the accounts were initially created there is no strong authentication used, how would, even in theory, it be possible to reauthenticate strongly after password was lost?
I think opt-out of password recovery choices on a line-item basis is not a bad concept.
For example, I’d want to opt out of recovery with account creation date. If anyone knows the date my gmail account was created, they most certainly aren’t me.
OTOH, recovery by receiving a token at a previously registered alternate email address seems relatively secure to me and I wouldn’t want to opt out of that.
Recovery by SMS to a previously registered phone likewise seems reasonably secure and I wouldn’t want to opt out of that, either.
Recovery by SMS to a phone number provided with the recovery request I would most certainly want to disable. (yes, some sites do this).
Recovery by having my password plain-text emailed to me at my alternate address (or worse, an address I supply at the time of recovery request), not so much. (yes, many sites actually do this)
Really, you don’t need to strongly authenticate a particular person for these accounts. You need, instead, to authenticate that the person attempting recovery is reasonably likely to be the person who set up the account originally, whether or not they are who they claimed to be at that time.
Perhaps some people would trust, if they could opt-in for reauthentication via some legal entity procuring such services. Then during account creation, you'd need to go through same authentication phase, perhaps tied to nationalID or comparable. This might be reasonable, most people probably already trust one of these for much more important authentication than email, but supporting all of them globally seems like very expensive proposal.
This also would take away from the benefits of having some level of anonymity in the account creation process, so I think this isn’t such a great idea on multiple levels.
YMMV.
Owen
In article <CAKnNFz_apy8KHBXj0umGoq6UfCD640Jtxe9A+2TqU-d761-eug@mail.gmail.com> you write:
Haha I cringe when I do a password recovery at a site and they either email the current pw to me in plain text or just as bad reset it then email it in plain text. Its really sad that stuff this bad is still so common.
If they do a reset, what difference does it make whether they send the password in plain text or as a one-time link? Either way, if a bad guy can read the mail, he can steal the account. Given the enormous scale of Gmail, I think they do a reasonable job of account security. If you want to make your account secure with an external account or an external token (a physical one like a yubikey or a software one like the authenticator app), you can. Or if you consider your account to be low value, you can treat it that way, too. R's, John
I get what you are saying but my point was more about lack of crypto or reversible crypto than stealing the account. I like what Owen is describing, they should present all account recovery options and let the user toggle on/off which ones they want to be usable this way the user can make their own decisions and live with their own choices. On Tue, May 26, 2015 at 12:06 PM, John Levine <johnl@iecc.com> wrote:
In article < CAKnNFz_apy8KHBXj0umGoq6UfCD640Jtxe9A+2TqU-d761-eug@mail.gmail.com> you write:
Haha I cringe when I do a password recovery at a site and they either email the current pw to me in plain text or just as bad reset it then email it in plain text. Its really sad that stuff this bad is still so common.
If they do a reset, what difference does it make whether they send the password in plain text or as a one-time link? Either way, if a bad guy can read the mail, he can steal the account.
Given the enormous scale of Gmail, I think they do a reasonable job of account security. If you want to make your account secure with an external account or an external token (a physical one like a yubikey or a software one like the authenticator app), you can.
Or if you consider your account to be low value, you can treat it that way, too.
R's, John
I get what you are saying but my point was more about lack of crypto or reversible crypto than stealing the account.
I am all in favor of using crypto when it improves security. But I am also in favor of not obsessing about it in places where it makes no difference.
I like what Owen is describing, they should present all account recovery options and let the user toggle on/off which ones they want to be usable this way the user can make their own decisions and live with their own choices.
Unfortunately, we have learned over and over again that the nerd instinct to push the security policy decisions onto civilians never ends well. Some people will check every box because more security is better, right? And then they're locked out and make expensive phone calls to your support desk. Others will uncheck every box because they just want to be able to log into the fripping account and it's your fault when their account is stolen. R's, John
On Tue, May 26, 2015 at 9:06 AM, John Levine <johnl@iecc.com> wrote:
If they do a reset, what difference does it make whether they send the password in plain text or as a one-time link? Either way, if a bad guy can read the mail, he can steal the account.
If they can e-mail you your existing password (*cough*Netgear*cough*), it means they are storing your credentials in the database un-encrypted. -A
*facepalm* Right. Sorry. Forgot which group I was addressing. ;) I swear half of the United States forgot their passwords over the three-day weekend. -A On Tue, May 26, 2015 at 12:39 PM, John R. Levine <johnl@iecc.com> wrote:
If they can e-mail you your existing password (*cough*Netgear*cough*), it means they are storing your credentials in the database un-encrypted.
What I had in mind was creating a new password and mailing you that.
R's, John
On Tue, May 26, 2015 at 12:28 PM, Aaron C. de Bruyn <aaron@heyaaron.com> wrote:
If they can e-mail you your existing password (*cough*Netgear*cough*), it means they are storing your credentials in the database un-encrypted.
No, it doesn't mean that at all. It means they are storing it unhashed which is probably what you mean. It may well be that they are storing it unencrypted, but you can't outright say that without extra knowledge. Scott
On Tue, May 26, 2015 at 4:10 PM, Scott Howard <scott@doc.net.au> wrote:
On Tue, May 26, 2015 at 12:28 PM, Aaron C. de Bruyn <aaron@heyaaron.com> wrote:
If they can e-mail you your existing password (*cough*Netgear*cough*), it means they are storing your credentials in the database un-encrypted.
No, it doesn't mean that at all. It means they are storing it unhashed which is probably what you mean.
Hi Scott, It means they're storing it in a form that reduces to plain text without human intervention. Same difference. Encrypted at rest matters not, if all the likely attack vectors go after the data in transit. Regards, Bill Herrin -- William Herrin ................ herrin@dirtside.com bill@herrin.us Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>
On May 27, 2015 at 10:28 bill@herrin.us (William Herrin) wrote:
On Tue, May 26, 2015 at 4:10 PM, Scott Howard <scott@doc.net.au> wrote:
On Tue, May 26, 2015 at 12:28 PM, Aaron C. de Bruyn <aaron@heyaaron.com> wrote:
If they can e-mail you your existing password (*cough*Netgear*cough*), it means they are storing your credentials in the database un-encrypted.
No, it doesn't mean that at all. It means they are storing it unhashed which is probably what you mean.
Hi Scott,
It means they're storing it in a form that reduces to plain text without human intervention. Same difference. Encrypted at rest matters not, if all the likely attack vectors go after the data in transit.
It matters a lot. It means their entire username/password collection can be compromised by various means including by an insider. The usual practice is to store a hash which cannot be reversed (at least not without astronomical computation.) Then when a password is presented (e.g., for login) the hash is computed on that cleartext password and the hashes are compared. Getting a copy of the database of hashes and login names is basically useless to an attacker. It's not encrypted in this case, it's hashed and only the hash is stored. The hash cannot be reversed, only compared to a re-hash of the cleartext password when entered. The OP was correct, if they can send you your cleartext password then their security practices are inadequate, period. Unless I misunderstand what you're saying (I sort of hope I do) this is Security 101. -- -Barry Shein The World | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo*
The OP was correct, if they can send you your cleartext password then their security practices are inadequate, period.
Unless I misunderstand what you're saying (I sort of hope I do) this is Security 101.
As I've said a couple of times already, but perhaps without the capital letters, from a security point of view, generating a NEW PASSWORD and sending it in cleartext is no worse than sending you a one time reset link. Either way, if a bad guy can intercept your mail, you lose. A few moments' thought will confirm this has nothing to do with the way passwords are stored within the mail system's database. R's, John
On May 27, 2015, at 11:22, John R. Levine <johnl@iecc.com> wrote:
As I've said a couple of times already, but perhaps without the capital letters, from a security point of view, generating a NEW PASSWORD and sending it in cleartext is no worse than sending you a one time reset link. Either way, if a bad guy can intercept your mail, you lose.
Well, no… a one time reset link is infinitely better than sending a cleartext password, assuming you don’t have to immediately change the password. A reset link, being usable once, means that you can detect if an attacker has already used it. If you use it first, the attacker has a useless link. If an attacker gets a cleartext password, you probably can’t detect interception. Cheers, -j
One weakness with sending a new cleartext password rather than a link is that a cleartext password (probably) has to be engineered to be easy to type in and maybe even remembered. Typically one uses some concatenation of CVC (consonant-vowel-consonant) with common punctuations and/or digits otherwise chosen randomly so something like pom%mur or kiv_ler for 7 chars anyhow, maybe add a digit or two, pom%mur87. A link can be much more random, just some long (64 char or more) string of hexified nonsense for example since the user presumably just clicks it and doesn't have to read it or type it in or worse remember it. SOOOOOO...an attacker could study your cleartext password generation algorithm which for a shorter, simpler, already structured cleartext password will be more likely to be predictable all else being equal. Perhaps the algorithm itself is is even available if you use some identifiable software package such as an e-commerce suite, I can't imagine every person selling paisley socks writes their own password generation algorithm. Or by studying the passwords it generates (create an acct, send yourself a few hundred or thousand.) I'm not just a-whistlin' dixie (I never a-whistle dixie! :-), I'd consider that a serious potential weakness adding more concern to choice of algorithms. -- -Barry Shein The World | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo*
On May 27, 2015 at 14:22 johnl@iecc.com (John R. Levine) wrote:
The OP was correct, if they can send you your cleartext password then their security practices are inadequate, period.
Unless I misunderstand what you're saying (I sort of hope I do) this is Security 101.
As I've said a couple of times already, but perhaps without the capital letters, from a security point of view, generating a NEW PASSWORD and sending it in cleartext is no worse than sending you a one time reset link. Either way, if a bad guy can intercept your mail, you lose.
A few moments' thought will confirm this has nothing to do with the way passwords are stored within the mail system's database.
Sure, I agree, but that's not what the post I was responding to was discussing so caps wouldn't make much difference. But only the link can be secured by asking a security question before first use. For the cleartext password an attacker only has to wait for you to answer the question and hope you don't immediately change the password. I suppose asking a question on first use of a new cleartext password AND forcing you to change that password immediately is about the same as the link, particularly if it doesn't let you use that same password. But storing cleartext passwords, encrypted or not, is a bad and indefensible practice. I remember a common dial-up login protocol which required the server to encrypt initial interaction with the customer's password so you absolutely had to have their cleartext password if they were ever to log in again. What was it, PAP or CHAP or something like that. Ugh, we resisted that. -- -Barry Shein The World | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo*
On Wed, May 27, 2015 at 1:51 PM, Barry Shein <bzs@world.std.com> wrote:
On May 27, 2015 at 10:28 bill@herrin.us (William Herrin) wrote:
On Tue, May 26, 2015 at 4:10 PM, Scott Howard <scott@doc.net.au> wrote:
It means they are storing it unhashed which is probably what you mean.
It means they're storing it in a form that reduces to plain text without human intervention. Same difference. Encrypted at rest matters not, if all the likely attack vectors go after the data in transit.
It matters a lot. [...] The OP was correct, if they can send you your cleartext password then their security practices are inadequate, period.
Am I speaking English? I thought I was speaking English.
Unless I misunderstand what you're saying (I sort of hope I do)
Yeah, I think you probably did since I was largely agreeing with you. What I was trying to say was that there wasn't a heck of a lot of difference between storing a user's password with reversible encryption and storing it in plain text. Both are supremely unsatisfactory. Reasonable security starts by not retaining the user's password at all. Keep only the non-reversible hash. Regards, Bill Herrin -- William Herrin ................ herrin@dirtside.com bill@herrin.us Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>
I am truly relieved that this was just a misunderstanding! -b On May 27, 2015 at 16:05 bill@herrin.us (William Herrin) wrote:
On Wed, May 27, 2015 at 1:51 PM, Barry Shein <bzs@world.std.com> wrote:
On May 27, 2015 at 10:28 bill@herrin.us (William Herrin) wrote:
On Tue, May 26, 2015 at 4:10 PM, Scott Howard <scott@doc.net.au> wrote:
It means they are storing it unhashed which is probably what you mean.
It means they're storing it in a form that reduces to plain text without human intervention. Same difference. Encrypted at rest matters not, if all the likely attack vectors go after the data in transit.
It matters a lot. [...] The OP was correct, if they can send you your cleartext password then their security practices are inadequate, period.
Am I speaking English? I thought I was speaking English.
Unless I misunderstand what you're saying (I sort of hope I do)
Yeah, I think you probably did since I was largely agreeing with you. What I was trying to say was that there wasn't a heck of a lot of difference between storing a user's password with reversible encryption and storing it in plain text. Both are supremely unsatisfactory. Reasonable security starts by not retaining the user's password at all. Keep only the non-reversible hash.
Regards, Bill Herrin
-- William Herrin ................ herrin@dirtside.com bill@herrin.us Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>
On Wed, May 27, 2015 at 01:51:35PM -0400, Barry Shein wrote:
Getting a copy of the database of hashes and login names is basically useless to an attacker.
Not any more, if the hash algorithm isn't sufficiently strong: 25-GPU cluster cracks every standard Windows password in <6 hours http://arstechnica.com/security/2012/12/25-gpu-cluster-cracks-every-standard... Quoting: "Gosney used the machine to crack 90 percent of the 6.5 million password hashes belonging to users of LinkedIn." Consider as well that not all attackers are interested in all accounts: imagine what this system (or a newer one, this is 2.5 years old) could do if focused on only one account. And of course epidemic password reuse means that cracked passwords are reasonably likely to work at multiple sites. And even if passwords aren't reused, there have now been so many breaches at so many places resulting in so many disclosed passwords that a discerning attacker could likely glean useful intelligence by studying multiple password choices made by a target. (We're all creatures of habit.) ---rsk
Good name in man and woman, dear my lord, Is the immediate jewel of their souls. Who steals my purse steals trash; 'tis something, nothing; 'Twas mine, 'tis his, and has been slave to thousands; But he that filches from me my good name Robs me of that which not enriches him, And makes me poor indeed. --Othello Act 3, Scene 3 -- -Barry Shein The World | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo*
LinkedIn used SHA-1, a fast algorithm. At 350-billion guesses per second on the mentioned rig for fast algorithms, yeah, you can get through a lot of passwords quickly. Hopefully LinkedIn has changed their ways. In that same article: "...functions such as Bcrypt, PBKDF2, and SHA512crypt are designed to expend considerably more time and computing resources to convert plaintext input into cryptographic hashes. As a result, the new cluster, even with its four-fold increase in speed, can make only 71,000 guesses against Bcrypt..." And if you use a different salt for each password stored with Bcrypt, the hacker must test each password separately -- no rainbow tables here. Unfortunately they don't say how many iterations of Bcrypt equals 71,000, since you can add more iterations of the algorithm. An example cipher text from bcrypt: $2a$13$Ejtc1pVjyLkZn4eU9FGCg.gOQ3QtbWOsUOvSUKbU2anywhoO04ESy $2a$ indicates the blowfish algorithm, $13$ is the cost factor (number of iterations), the first 22 chars after are the salt and the rest is the cipher text. The higher the number of iterations, the harder computationally it is to go from a password to the cipher text. As hardware improves, the iterations should increase. I was thinking about using the last 2 digits of the year as the cost factor, but that might not scale with hardware linearly. Bcrypt or PBKDF2 with random salts per password is really what anyone storing passwords should be using today. Beckman On Wed, 27 May 2015, Rich Kulawiec wrote:
On Wed, May 27, 2015 at 01:51:35PM -0400, Barry Shein wrote:
Getting a copy of the database of hashes and login names is basically useless to an attacker.
Not any more, if the hash algorithm isn't sufficiently strong:
25-GPU cluster cracks every standard Windows password in <6 hours http://arstechnica.com/security/2012/12/25-gpu-cluster-cracks-every-standard...
Quoting:
"Gosney used the machine to crack 90 percent of the 6.5 million password hashes belonging to users of LinkedIn."
Consider as well that not all attackers are interested in all accounts: imagine what this system (or a newer one, this is 2.5 years old) could do if focused on only one account.
And of course epidemic password reuse means that cracked passwords are reasonably likely to work at multiple sites.
And even if passwords aren't reused, there have now been so many breaches at so many places resulting in so many disclosed passwords that a discerning attacker could likely glean useful intelligence by studying multiple password choices made by a target. (We're all creatures of habit.)
---rsk
--------------------------------------------------------------------------- Peter Beckman Internet Guy beckman@angryox.com http://www.angryox.com/ ---------------------------------------------------------------------------
On Wed, May 27, 2015 at 6:04 PM, Peter Beckman <beckman@angryox.com> wrote: [snip]
I was thinking about using the last 2 digits of the year as the cost factor, but that might not scale with hardware linearly.
It is strongly recommended that when used for password storage, the work factor for BCRYPT, SCRYPT, or PBKDF2 be hand-tuned based on the current best available consumer desktop computing hardware. Whenever it is manually adjusted; it should be tuned so that 1 password hash generation on a newly generated hash takes a minimum 500 milliseconds average at full throughput on the best current generally available consumer hardware. Or for an application where performance is more critical than security.... no less than 100ms on the server hardware. Today; I believe the baseline would be a workstation with 4 5th generation Intel i7 3.1GHz Quad-Core procs. And I would suggest SCrypt() with a hefty selection for required amount of RAM to compute the hash; in order to help foil attempts to accelerate a hash-breaking process using GPU or FPGA technology.
Bcrypt or PBKDF2 with random salts per password is really what anyone storing passwords should be using today.
Beckman -- -JH
Bcrypt or PBKDF2 with random salts per password is really what anyone storing passwords should be using today.
Indeed. A while ago I had a brainfart and presented it in a draft: https://tools.ietf.org/html/draft-kistel-encrypted-password-storage-00 It seemed like a good idea at the time :-) It didn't gain much traction though. Robert
On Thu, May 28, 2015 at 5:29 AM, Robert Kisteleki <robert@ripe.net> wrote:
Bcrypt or PBKDF2 with random salts per password is really what anyone storing passwords should be using today.
Indeed. A while ago I had a brainfart and presented it in a draft: https://tools.ietf.org/html/draft-kistel-encrypted-password-storage-00
It seemed like a good idea at the time :-) It didn't gain much traction though.
I get the feeling that, along with things like 'email address verification' in javascript form things, passwd storage and management is something done via a few (or a bunch of crappy home-grown) code bases. Seems like 'find the common/most-used' ones and fix them would get some mileage? I don't imagine that 'dlink' (for example) is big on following rfc stuff for their web-interface programming? (well, at least for things like 'how should we store passwds?')
On May 28, 2015 10:11 AM, "Christopher Morrow" <morrowc.lists@gmail.com> wrote:
On Thu, May 28, 2015 at 5:29 AM, Robert Kisteleki <robert@ripe.net> wrote:
Bcrypt or PBKDF2 with random salts per password is really what anyone storing passwords should be using today.
One thing to remember is the hardware determines number of rounds. So while my LUKS (PBKDF2) pass on my laptop or servers have a few 10k rounds, that same pass on a Pi or so would only have 1k rounds (minimum rec).
I get the feeling that, along with things like 'email address verification' in javascript form things, passwd storage and management is something done via a few (or a bunch of crappy home-grown) code bases.
Not generally passwords per se but session tokens and the like, sure (almost as bad).
Seems like 'find the common/most-used' ones and fix them would get some mileage? I don't imagine that 'dlink' (for example) is big on following rfc stuff for their web-interface programming? (well, at least for things like 'how should we store passwds?')
Heh, I started on a fuzzer that'd take a few strings and run them through recipes (base 32/64, rot, xor 1 or 0, etc) and try to find human strings along the way. If multiple strings match a recipe, you can generate your own sessions.
On 05/28/2015 02:29 AM, Robert Kisteleki wrote:
Bcrypt or PBKDF2 with random salts per password is really what anyone storing passwords should be using today. Indeed. A while ago I had a brainfart and presented it in a draft: https://tools.ietf.org/html/draft-kistel-encrypted-password-storage-00
It seemed like a good idea at the time :-) It didn't gain much traction though.
Or you could choose to not store any form of password at all on the server: https://datatracker.ietf.org/doc/rfc7486/ Mike
On (2015-05-26 17:44 +0200), Owen DeLong wrote: Hey,
I think opt-out of password recovery choices on a line-item basis is not a bad concept.
This sounds reasonable. At least then you could decide which balance of risk/convenience fits their use-case for given service.
OTOH, recovery by receiving a token at a previously registered alternate email address seems relatively secure to me and I wouldn???t want to opt out of that.
It's probably machine sent in seconds or minute after request, so doing short-lived BGP hijack of MX might be reasonably easy way to get the email.
Recovery by SMS to a previously registered phone likewise seems reasonably secure and I wouldn???t want to opt out of that, either.
I have tens of coworkers who could read my SMS.
Really, you don???t need to strongly authenticate a particular person for these accounts. You need, instead, to authenticate that the person attempting recovery is reasonably likely to be the person who set up the account originally, whether or not they are who they claimed to be at that time.
As long as user has the power to choose which risks are worth carrying, I think it's fine. For my examples, I wouldn't care about email/SMS risk if it's linkedin/twitter/facebook account. But if it's my domain hoster, I probably wouldn't want to carry either risk, as the whole deck of cards collapses if you control my domains (all email recoveries compromised) -- ++ytti
On Tue, 26 May 2015 19:11:51 +0300, Saku Ytti said:
OTOH, recovery by receiving a token at a previously registered alternate email address seems relatively secure to me and I wouldn???t want to opt out of that.
It's probably machine sent in seconds or minute after request, so doing short-lived BGP hijack of MX might be reasonably easy way to get the email.
To be fair, if your e-mail address is high enough value that somebody is willing to risk getting caught doing a BGP hijack, maybe you have bigger problems to worry about.
On Tue, May 26, 2015 at 2:15 PM, <Valdis.Kletnieks@vt.edu> wrote:
On Tue, 26 May 2015 19:11:51 +0300, Saku Ytti said:
OTOH, recovery by receiving a token at a previously registered alternate email address seems relatively secure to me and I wouldn???t want to opt out of that.
It's probably machine sent in seconds or minute after request, so doing short-lived BGP hijack of MX might be reasonably easy way to get the email.
To be fair, if your e-mail address is high enough value that somebody is willing to risk getting caught doing a BGP hijack, maybe you have bigger problems to worry about.
I suppose the meta of this whole conversation is for the OP: "Sure, there are issues with just about every account-recovery setup out there. Where you have X-hundreds of millions of 'not nanog' level users interacting and needing passwd recovery to work reliably and somewhat securely, how would you accomplish this?" Tossing grenades in the crowded room is cool and all, but ... you clearly have some thoughts about options/improvements/etc you might get more useful traction by proposing them.
In message <20150526161151.GA14841@pob.ytti.fi>, Saku Ytti writes:
On (2015-05-26 17:44 +0200), Owen DeLong wrote:
Hey,
I think opt-out of password recovery choices on a line-item basis is not a bad concept.
This sounds reasonable. At least then you could decide which balance of risk/convenience fits their use-case for given service.
OTOH, recovery by receiving a token at a previously registered alternate e mail address seems relatively secure to me and I wouldn???t want to opt out of that.
It's probably machine sent in seconds or minute after request, so doing short-lived BGP hijack of MX might be reasonably easy way to get the email.
Which is easily prevented by authenticating the MX when connecting. Something which as been recommended practice for as long as SMTP has existed. HELO provided weak authentication. We now know and documented how to do this securely on a global scale, we just need to do it. See draft-ietf-dane-smtp-with-dane. You have added the TLSA records for you MTA and signed your zones? You have updated your MTA to support DANE? [ Need to nag ops to add TLSA records for the MX's. We have them for www.isc.org. ] Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On May 26, 2015, at 6:11 PM, Saku Ytti <saku@ytti.fi> wrote:
On (2015-05-26 17:44 +0200), Owen DeLong wrote:
Hey,
I think opt-out of password recovery choices on a line-item basis is not a bad concept.
This sounds reasonable. At least then you could decide which balance of risk/convenience fits their use-case for given service.
OTOH, recovery by receiving a token at a previously registered alternate email address seems relatively secure to me and I wouldn???t want to opt out of that.
It's probably machine sent in seconds or minute after request, so doing short-lived BGP hijack of MX might be reasonably easy way to get the email.
If someone has the ability to hijack your BGP, then you’ve got bigger problems than having them take over your Gmail account.
Recovery by SMS to a previously registered phone likewise seems reasonably secure and I wouldn???t want to opt out of that, either.
I have tens of coworkers who could read my SMS.
That’s interesting… Why do you choose to give access to your personal SMS messages to so many of your coworkers?
Really, you don???t need to strongly authenticate a particular person for these accounts. You need, instead, to authenticate that the person attempting recovery is reasonably likely to be the person who set up the account originally, whether or not they are who they claimed to be at that time.
As long as user has the power to choose which risks are worth carrying, I think it's fine. For my examples, I wouldn't care about email/SMS risk if it's linkedin/twitter/facebook account. But if it's my domain hoster, I probably wouldn't want to carry either risk, as the whole deck of cards collapses if you control my domains (all email recoveries compromised)
We agree that different risks are appropriate for different levels of sensitivity. Owen
On 27 May 2015, at 13:19, Owen DeLong wrote:
If someone has the ability to hijack your BGP, then you’ve got bigger problems than having them take over your Gmail account.
Could we perhaps summarise this entire thread with "if you have tighter security requirements for your e-mail than a particular e-mail provider can give you, host your e-mail somewhere else"? Also, if you get a stabbing pain in your eye every time you drink tea, take the spoon out of the cup. Joe
On (2015-05-27 14:19 +0200), Owen DeLong wrote: Hey,
If someone has the ability to hijack your BGP, then you???ve got bigger problems than having them take over your Gmail account.
This is second reply to this notion. I don't understand what is attempted to communicate. I'm sure no one on nanog thinks BGP hijacks are rare, difficult or yield to consequences when called out.
That???s interesting??? Why do you choose to give access to your personal SMS messages to so many of your coworkers?
I don't, but they can provision my number to any SIM they want to. -- ++ytti
I also suspect not every telco validates number porting requests against social engineering properly. A telephone number isn't something you have, it is something your provider has. On Wednesday, May 27, 2015, Saku Ytti <saku@ytti.fi> wrote:
On (2015-05-27 14:19 +0200), Owen DeLong wrote:
Hey,
If someone has the ability to hijack your BGP, then you???ve got bigger problems than having them take over your Gmail account.
This is second reply to this notion. I don't understand what is attempted to communicate. I'm sure no one on nanog thinks BGP hijacks are rare, difficult or yield to consequences when called out.
That???s interesting??? Why do you choose to give access to your personal SMS messages to so many of your coworkers?
I don't, but they can provision my number to any SIM they want to.
-- ++ytti
"Security is an illusion" - Confucius probably On Wed, May 27, 2015 at 8:42 AM, Joel Maslak <jmaslak@antelope.net> wrote:
I also suspect not every telco validates number porting requests against social engineering properly.
A telephone number isn't something you have, it is something your provider has.
On Wednesday, May 27, 2015, Saku Ytti <saku@ytti.fi> wrote:
On (2015-05-27 14:19 +0200), Owen DeLong wrote:
Hey,
If someone has the ability to hijack your BGP, then you???ve got bigger problems than having them take over your Gmail account.
This is second reply to this notion. I don't understand what is attempted to communicate. I'm sure no one on nanog thinks BGP hijacks are rare, difficult or yield to consequences when called out.
That???s interesting??? Why do you choose to give access to your personal SMS messages to so many of your coworkers?
I don't, but they can provision my number to any SIM they want to.
-- ++ytti
On Wed, May 27, 2015 at 8:42 AM, Joel Maslak <jmaslak@antelope.net> wrote:
I also suspect not every telco validates number porting requests against social engineering properly.
What national wireless provider _does_ validate porting requests against social engineering? As far as I knew, as soon as the gaining provider receives the filled out online form or written form, with the billing address, Or copy of a bill from the old provider printed off from the losing provider's web portal signed off with a forged signature from the scammer (All information that can be derived through pre-texting or social engineering), The gaining wireless carrier can proceed, and will proceed with a simple port without having to call the number for approval. The sufficiently evil scammer will have the wireless number ported to their pre-paid cell phone within 48 hours, and be ready to receive insecure SMS message from the target's online banking service to confirm the second factor for login. -- -JH
On Wed, 27 May 2015 16:11:19 +0300, Saku Ytti said:
This is second reply to this notion. I don't understand what is attempted to communicate. I'm sure no one on nanog thinks BGP hijacks are rare, difficult or yield to consequences when called out.
What *is* rare is a BGP hijack done solely to intercept a confirmation e-mail sent to Joe Sixpack when he's trying to get his Gmail account back. Can anybody provide a *single* example of that being done? Now, if it's Joe CEO or Joe Prime Minister, the calculus changes a bit. But as I said - at that point, you have bigger things to worry about.
On 05/26/2015 08:44 AM, Owen DeLong wrote:
I think opt-out of password recovery choices on a line-item basis is not a bad concept.
For example, I’d want to opt out of recovery with account creation date. If anyone knows the date my gmail account was created, they most certainly aren’t me.
OTOH, recovery by receiving a token at a previously registered alternate email address seems relatively secure to me and I wouldn’t want to opt out of that.
(( many more snipped ))
I would definitely opt-out from any kind of "secret questions" that I couldn't type by myself. Many many sites still think this is a good idea. Best regards.
Somewhat in the weeds here, but I still find it odd/curious that Google is still using SHA-1 fingerprinted SSL certificates. Weren't they making a big deal of pushing SHA-2 fingerprinted SSL certs a while back? On Wed, May 27, 2015 at 12:16 AM, Octavio Alvarez <octalnanog@alvarezp.org> wrote:
On 05/26/2015 08:44 AM, Owen DeLong wrote:
I think opt-out of password recovery choices on a line-item basis is not a bad concept.
For example, I’d want to opt out of recovery with account creation date. If anyone knows the date my gmail account was created, they most certainly aren’t me.
OTOH, recovery by receiving a token at a previously registered alternate email address seems relatively secure to me and I wouldn’t want to opt out of that.
(( many more snipped ))
I would definitely opt-out from any kind of "secret questions" that I couldn't type by myself.
Many many sites still think this is a good idea.
Best regards.
-- Blair Trosper p.g.a. S2 Entertainment Partners Desk: 469-333-8008 Cell: 512-619-8133 Agent/Rep: WME (Los Angeles, CA) - 310-248-2000 PR/Manager: BORG (Dallas, TX) - 844-THE-BORG
On Wed, May 27, 2015 at 1:16 AM, Octavio Alvarez <octalnanog@alvarezp.org> wrote:
I would definitely opt-out from any kind of "secret questions" that I couldn't type by myself.
Many many sites still think this is a good idea.
My first dog's name was a random and unpronounceable 30-character string. -Bill -- William Herrin ................ herrin@dirtside.com bill@herrin.us Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>
On Thu, May 28, 2015 at 03:13:37PM -0400, William Herrin wrote:
On Wed, May 27, 2015 at 1:16 AM, Octavio Alvarez <octalnanog@alvarezp.org> wrote:
I would definitely opt-out from any kind of "secret questions" that I couldn't type by myself.
Many many sites still think this is a good idea.
My first dog's name was a random and unpronounceable 30-character string.
I think this (Bill's) is a very good practice. It's not that difficult to enumerate the name of every pro sports team in the US, the 100 most popular dog names, the 200 most common street names, etc. This attack can be mitigated by limiting attempts...but of course if that's done, then it's possible for an attacker to lock out the real owner by just hammering away constantly using assorted botnet hosts. ---rsk
On 28 May 2015, at 22:18, Rich Kulawiec wrote:
On Thu, May 28, 2015 at 03:13:37PM -0400, William Herrin wrote:
My first dog's name was a random and unpronounceable 30-character string.
I think this (Bill's) is a very good practice.
That's what I should do. Instead, I pull down the list of candidate questions and think to myself... - I didn't go to a high school - I don't understand this other high school reference - I don't watch sports - I don't have a favourite sports team - I wonder vaguely whether that question actually had anything to do with sports - I don't have a favourite pet - I don't know my grandmother's middle name, and never did - I don't have a favourite colour - I've never owned a dog - Are pets ever really owned? - Doesn't that speak to the denegration of others based on species? - Aren't we against that? and around this point, I start to think - I've had enough of this - this is too hard - I don't even remember what I am signing up for at this point - I am going to look for amusing cats on youtube Joe
Op 29 mei 2015, om 08:42 heeft Joe Abley <jabley@hopcount.ca> het volgende geschreven:
[...] and around this point, I start to think
- I've had enough of this - this is too hard - I don't even remember what I am signing up for at this point - I am going to look for amusing cats on youtube
Good plan, Sander
I use completely random strings for security questions. The company doesn't care what my answer is, so instead of knowing that my favorite sports team is [REDACTED] they can see that it is "WheF7?ydk/cBG8MgZf7w" Go WheF7?ydk/cBG8MgZf7w! I store all of the security questions in my password manager (1Password), and though annoying if prompted for them often, my account is more secure as a result. It's also a lot of fun when you call in and they ask you the answer to your security question. Just because someone asks you a question it does not require you to give an answer they expect. (Or any answer) Beckman On Fri, 29 May 2015, Joe Abley wrote:
On Thu, May 28, 2015 at 03:13:37PM -0400, William Herrin wrote:
My first dog's name was a random and unpronounceable 30-character string.
That's what I should do. Instead, I pull down the list of candidate questions and think to myself...
- I didn't go to a high school - I don't understand this other high school reference - I don't watch sports - I don't have a favourite sports team - I wonder vaguely whether that question actually had anything to do with sports - I don't have a favourite pet - I don't know my grandmother's middle name, and never did - I don't have a favourite colour - I've never owned a dog - Are pets ever really owned? - Doesn't that speak to the denegration of others based on species? - Aren't we against that?
and around this point, I start to think
- I've had enough of this - this is too hard - I don't even remember what I am signing up for at this point - I am going to look for amusing cats on youtube
--------------------------------------------------------------------------- Peter Beckman Internet Guy beckman@angryox.com http://www.angryox.com/ ---------------------------------------------------------------------------
On 29/05/15 10:35 -0400, Peter Beckman wrote:
I use completely random strings for security questions. The company doesn't care what my answer is, so instead of knowing that my favorite sports team is [REDACTED] they can see that it is "WheF7?ydk/cBG8MgZf7w"
Go WheF7?ydk/cBG8MgZf7w!
I store all of the security questions in my password manager (1Password), and though annoying if prompted for them often, my account is more secure as a result. It's also a lot of fun when you call in and they ask you the answer to your security question.
Just because someone asks you a question it does not require you to give an answer they expect. (Or any answer)
Beckman
Good in principle, however I'll bet you 20$ that with this state, if I get on the phone with support, and they ask for the answer to the security question, simply replying "Is it a bunch of gharbled chracters, about 20 of em?" Will be more than enough to get me in. Use 3-4 dictionary words.
I can't write my autobiography because it'd contain the answers to too many security questions! -- -Barry Shein The World | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo*
Use a ghost writer. ;-) Owen
On May 29, 2015, at 10:42 AM, Barry Shein <bzs@world.std.com> wrote:
I can't write my autobiography because it'd contain the answers to too many security questions!
-- -Barry Shein
The World | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo*
On Fri, May 29, 2015 at 1:42 AM, Joe Abley <jabley@hopcount.ca> wrote:
That's what I should do. Instead, I pull down the list of candidate questions and think to myself... ... - I don't have a favourite colour
My favourite color is Red, but the answer is rejected because it's less than 6 characters long; it turns out your favorite color can be Yellow, Orange, or Purple, but not Blue, Green, Gray, or Pink.
and around this point, I start to think - I am going to look for amusing cats on youtube
After finding one, now you have a favorite pet.... I suggest generating a random string for secret answer questions, just as if it was another password. Write down the answers; stick them in a lockbox. Some websites will prompt for the answers during normal login later as if answering personal questions was some legitimate way to confirm a login from an "untrusted" computer....... in that case, save a copy as secure notes in the password vault, Or put the answers to a .txt file encrypt - using GPG. It is a bit bogus: the whole notion of asking in a format where the response can easily be automatically entered, for authentication purposes, the sort of questions about you that would be easily looked up using public records, or that distant acquaintenances and former schoolmates would know the answers to... There is an improvement in use cases where the traditional response is just to accept the request and e-mail a new temporary password. In cases where "the answer" is used as if it was a second factor, that's fairly obnoxious and generating a false sense of security in the process. In cases where it can be used to reset password directly or call in over the phone and reset a password or change the account --- the strength of the password is weakened to the strength of the weakest security answer.
Joe -- -JH
On Thu, 28 May 2015, Rich Kulawiec wrote:
I think this (Bill's) is a very good practice. It's not that difficult to enumerate the name of every pro sports team in the US, the 100 most popular dog names, the 200 most common street names, etc. This attack can be mitigated by limiting attempts...but of course if that's done, then it's possible for an attacker to lock out the real owner by just hammering away constantly using assorted botnet hosts.
There are providers (banks, etc) who will disable an online account that has had X failed login attempts. While that's good for preventing $bad_guy from continuing to try to brute-force-guess the password, it creates a nominal DoS condition for the legitimate owner who then has to contact the provider and go through their password reset procedure. In most of the cases I've seen, the provider is not well equipped to block login attempts for $legit_user from whatever address range is doing the brute-forcing (possibly spoofed / botted anyway). jms
On Fri, May 29, 2015 at 12:32:34PM -0400, Justin M. Streiner wrote:
There are providers (banks, etc) who will disable an online account that has had X failed login attempts. While that's good for preventing $bad_guy from continuing to try to brute-force-guess the password, it creates a nominal DoS condition for the legitimate owner who then has to contact the provider and go through their password reset procedure.
This is why automatic lockout procedures are a problem for some operations, particularly those which are known to create user account names based on algorithms like "first initial + last name, truncated to 8 characters". It's not at all difficult to construct a list of valid (or probably-valid) usernames at such sites, hit them all repeatedly from distributed botnets (N-1 times from any one address, where N times would trigger IP-based blocking methods) and thus effectively DoS a decent fraction of the users. ---rsk
Hi, On Tue, May 26, 2015 at 3:26 PM, Markus <universe@truemetal.org> wrote:
Did you know that anyone, anywhere in the world can get into a gmail account merely by knowing its creation date (month and year is sufficient) and the last login date (try "today")? What a joke.
Can you not set account recory options which change the way password reset requests are handled. https://support.google.com/accounts/answer/183723 Gives some guidance? Alex
Perhaps this is still a void in the market? A business which operates small officers at which you can real-world verify your personal being using the most solid evidence available (perhaps in cooperation with governments) for that location/country which works together with the sorts of big-@random-webservice to help recover information? That would remove the need for weak idea's. Either you setup and use a very solid recovery method or you present yourself (or perhaps a family member in case of (emergency/deceased/etc')). With kind regards, Thijs Stuurman Infrastructure & Solutions IS (internedservices) Group Wielingenstraat 8 | 1441 ZR Purmerend | The Netherlands T: +31(0)299476185 | M: +31(0)624366778 W: http://www.is.nl | L: http://nl.linkedin.com/in/thijsstuurman -----Oorspronkelijk bericht----- Van: NANOG [mailto:nanog-bounces@nanog.org] Namens Alex Brooks Verzonden: Tuesday, May 26, 2015 5:32 PM Aan: Markus; nanog Onderwerp: Re: gmail security is a joke Hi, On Tue, May 26, 2015 at 3:26 PM, Markus <universe@truemetal.org> wrote:
Did you know that anyone, anywhere in the world can get into a gmail account merely by knowing its creation date (month and year is sufficient) and the last login date (try "today")? What a joke.
Can you not set account recory options which change the way password reset requests are handled. https://support.google.com/accounts/answer/183723 Gives some guidance? Alex
On 26 May 2015 at 11:32, Alex Brooks <askoorb+nanog@gmail.com> wrote:
Can you not set account recory options which change the way password reset requests are handled. https://support.google.com/accounts/answer/183723 Gives some guidance?
Alex
Unfortunately, setting these options does not disable the separate "account recovery form" listed at the bottom of the page, and it is this form that allows you to login with any previous password and to bypass 2-factor auth. I must admit I was surprised by this when I tried it just now. I guess it's time to rethink using Google as a primary account...
On May 27, 2015, at 8:09 AM, Harald Koch <chk@pobox.com> wrote:
On 26 May 2015 at 11:32, Alex Brooks <askoorb+nanog@gmail.com> wrote:
Can you not set account recory options which change the way password reset requests are handled. https://support.google.com/accounts/answer/183723 Gives some guidance?
Alex
Unfortunately, setting these options does not disable the separate "account recovery form" listed at the bottom of the page, and it is this form that allows you to login with any previous password and to bypass 2-factor auth.
I must admit I was surprised by this when I tried it just now. I guess it's time to rethink using Google as a primary account...
According to this page, the 2-factor authentication does kick in when you finally try to reset the password. http://webapps.stackexchange.com/questions/27258/is-there-a-way-of-disabling... <http://webapps.stackexchange.com/questions/27258/is-there-a-way-of-disabling-googles-password-recovery-feature> “… I was presented with an emailed link to a reset page. When I clicked that link, since I have two-step verification set up, I was presented with a demand for a number provided by the Google Authenticator app on my phone. I provided that number and only then was I allowed to reset the password.” AK
On Wed, 27 May 2015 09:13:47 +0530, Anil Kumar said:
that link, since I have two-step verification set up, I was presented with a demand for a number provided by the Google Authenticator app on my phone. I provided that number and only then was I allowed to reset the password.
And you have to pre-register the phone number. Sounds about as secure as you're going to get when trying to scale to 10 digits of users.... And as I said earlier - if your threat model involves needing more security than that, you have bigger problems.. :)
You can also register a U2F key. On Wed, May 27, 2015 at 3:17 AM, <Valdis.Kletnieks@vt.edu> wrote:
On Wed, 27 May 2015 09:13:47 +0530, Anil Kumar said:
that link, since I have two-step verification set up, I was presented with a demand for a number provided by the Google Authenticator app on my phone. I provided that number and only then was I allowed to reset the password.
And you have to pre-register the phone number.
Sounds about as secure as you're going to get when trying to scale to 10 digits of users....
And as I said earlier - if your threat model involves needing more security than that, you have bigger problems.. :)
On 26 May 2015 at 23:43, Anil Kumar <akumar@anilkumar.com> wrote:
According to this page, the 2-factor authentication does kick in when you finally try to reset the password.
http://webapps.stackexchange.com/questions/27258/is-there-a-way-of-disabling...
“… I was presented with an emailed link to a reset page. When I clicked that link, since I have two-step verification set up, I was presented with a demand for a number provided by the Google Authenticator app on my phone. I provided that number and only then was I allowed to reset the password.”
Y'all are way too trusting ;) If I recall from a brief experiment yesterday, three of the four options on that page are variations on "I'd like to bypass 2-factor authentication". There is really no point in any of Google's fancy account security if I can bypass all of it using Google's Identity Verification process, especially if that process is based on PII that isn't terribly difficult to obtain. This is just a variation on Apple's "give us the last four digits of your credit card to reset your password" gigantic security failure, and frankly I expected better from Google. Silly me. -- Harald (who once upon a time worked in the IAM space ;)
On Wed, May 27, 2015 at 4:52 PM, Harald Koch <chk@pobox.com> wrote:
Y'all are way too trusting ;)
Or we are much more comfortable with our knowledge. Six in one,....
If I recall from a brief experiment yesterday, three of the four options on that page are variations on "I'd like to bypass 2-factor authentication". There is really no point in any of Google's fancy account security if I can bypass all of it using Google's Identity Verification process, especially if that process is based on PII that isn't terribly difficult to obtain.
I think you are overly simplifying a piece of a very large, very complicated, highly dynamic, and daily reviewed, security pipeline. Google's Account security is not a 1 man in the basement operation. You tell me the Sender, time, last Received line, and byte size, of all the emails I received on 1-Jan-2015 and I will give you $100 per email.... or this thread can just die a miserable hypothetical death that it deserves. -Jim P.
On Tue, May 26, 2015 at 10:26 AM, Markus <universe@truemetal.org> wrote:
Did you know that anyone, anywhere in the world can get into a gmail account merely by knowing its creation date (month and year is sufficient) and the last login date (try "today")? What a joke.
We don't even know if this email originated by Markus himself. :-) As for security, the default access for mobile devices (which require no further credentials for Mail, Web, SMS) is a swipe. I too wish the world was bulletproof from birth, but it's not. -Jim P.
participants (34)
-
Aaron C. de Bruyn -
Alex Brooks -
Anil Kumar -
Barry Shein -
Blair Trosper -
chris -
Christopher Morrow -
Harald Koch -
James Downs -
Jim Popovitch -
Jimmy Hess -
Joe Abley -
Joel Maslak -
John Levine -
John R. Levine
-
John Souvestre -
Justin M. Streiner -
Mark Andrews -
Markus -
Michael Thomas -
Octavio Alvarez -
Owen DeLong -
Peter Beckman -
Rafael Possamai -
Rich Kulawiec -
Richo Healey -
Robert Kisteleki -
Saku Ytti -
Sander Steffann -
Scott Howard -
shawn wilson -
Thijs Stuurman -
Valdis.Kletnieks＠vt.edu -
William Herrin