Comment SoylentNews is people. (Score 1) 385
It's a shame we can't do something similar to get some changes made
It's a shame we can't do something similar to get some changes made
well... how about a cookie?
Or how about a few quintillion cookies?
STOP USING CREDIT CARDS! Use cash whenever possible.
Sometimes it isn't possible. What should someone use to buy goods that aren't sold in any store within his home town, such as electronic parts in the post-RadioShack era?
Speaker's corner in Hyde Park has been the icon for that tradition since the 1850's.
Speaker's Corner isn't anything like the out-of-sight, out-of-mind free speech zones in the United States, is it?
Gorillaz? I thought keeping the snack counter at Feel Good Inc. supplied with Milk Duds took an American Express business card.
You could implant a cryptographic radio transponder with a 666-bit keypair in people's forehead or right hand. The plus side is that it'd combine the positive aspects of a "something you have" transponder with biometrics' resistance to loss or theft. The minus side is protests from Christians who think it's the mark of the Beast mentioned in the revelation to John of Patmos.
* Actual theft, not copying.
Now I'm quite sure you've never done any embedded work. Debian USED to be a good base for an embedded system.
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
I just use a PRNG. If I need it as a GUID, I request 120 random bits and format them as a type 4 UUID. Is that good enough?
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?
security questions
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.
An Ada exception is when a routine gets in trouble and says 'Beam me up, Scotty'.
