I thought MS-DOS didn't get folders until 2.0, and Mac OS didn't get folders until HFS in System 2.1.
This way someone intercepting SMTP doesn't get access to hijack account
Then how would a reset work? Or do all subscribers to your service additionally need to subscribe to mobile phone service on a supported carrier?
The combination of time (the UUID can be time boxed), activity (a successful login nullifies the UUID), and possession (control of the account's registered email address)
My concern is how to keep someone between your server and the subscriber's MUA from compromising "possession", or how to establish "possession" the first time.
Assuming the coders didn't decide to come up with their own GUID generation algorithm that is easily reverse engineered and seeded
Or to put it shorter: "Passwords and password reset codes go in separate fields."
I've implemented a similar system that keeps the hashed password and the one-time-use code in separate fields of the user table. I just wondered if there was any good way to protect the "login ticket" (the mail containing the one-time-use code) from interception in the 24 hours between when it is sent and the expiration time that we store.
In the message the portal not only assigned my username, but it also listed a temporary password that's good for 30 days! All of this transmitted cleartext.
This use of a one-time, soon-expiring autogenerated password is common in flows that include the step "To reset your password, confirm your e-mail address" or "To opt in to e-mail notifications, confirm your e-mail address". Is there an alternative, other than to either A. mail all customers a second factor of authentication used to reset a password, or B. require all customers to subscribe to mobile phone service with unlimited texting to receive resets through SMS?
Send an e-mail with a verification URL
How do you encrypt this unique verification URL on its way to the subscriber to your service?
I'm sorry; I misread this as "security theater questions". See "The Curse of the Secret Question" by Bruce Schneier and "Wish-It-Was Two Factor" by Alex Papadimoulis.
The questions we ask are not something that would normally be found in a users inbox
A lot of time, the answers to security theater questions are things that would be in a user's Facebook timeline, such as the name of the middle school that the user attended.
That just means you must make more than one cut to isolate the segment you're working on, or you have to get your splice in while the trucks are on the way to the decoy cut.
So how do you encrypt this UUID? And what do you send for a password reset?
If you want a bit more security than this you could do something like text the user the token instead of baking it into the URL.
But how do you send a text to the number "I don't have a cell phone" or to a land line? I tried to send the code to a land line on a couple sites and got "Unsupported carrier".
and send them an email with a link (containing a random hash that's indexed to that user in the DB) to verify the email address
But how would you encrypt "a random hash" on its way to the e-mail recipient?
Why would you need to generate a password for them, especially if you're going to email it plaintext and make them change it anyway?
Because this one-time random password serves precisely the same purpose as "a random hash" that you mention.
“This is a big shock,” said Suchitra Sebastian, a condensed matter physicist at the University of Cambridge whose findings appeared today in an advance online edition of the journal Science. Insulators and metals are essentially opposites, she said. “But somehow, it’s a material that’s both. It’s contrary to everything that we know.”
Link to Original Source
Unfortunately, in this case the pain spreads around. The sluggard isn't necessary the one who suffers for it.
ISPs get stuck dealing with NAT because too many servers are only reachable via v4, servers get stuck scrounging v4 addresses (possibly at great expense) because too many ISPs don't support v6, etc.
Or are you simply alergic to the d,e,m,s,t and y?
You've obviously never worked on an embedded system. Sometimes in that space, you throw out absolutely anything and everything you don't absolutely positively have to include. That's why busybox exists and has a config menu that lets you choose exactly what commands to support. Likewise, dietlibc for when glibc is too big.
A simple firewall rule will provide all of the security NAT would provide and with a lower load on the firewall.
Just enable connection tracking, accept incoming related packets and drop the rest.