Alright, here's the story:
I'm getting married soon, and I'd like to create a website (or an app).
Obviously, I'd like that only guests could access to it.
So I was thinking about a system where it would require a security code to sign up.
The problem is that I do not trust anyone not to be silent about the code, so I was thinking about giving a different code for every couple (or family) of invited people.
On the sign up form, I would then verify that the entered code has not already been used.
But since I don't know who will sign up to the app, and I don't really have time to manually register each guest, I won't have a database with what code has been provided to whom information.
So, I need an algorithm to generate a random security code, and the reversed one, to check if a given string is a validate security code
I need the algorithm to be complex enough so people could not guess what's the magic behing the code they received. (I know, it feels pretty paranoid)
The generated Securiy Code should be pretty simple, like 6 to 8 characters (mix of digits, upper and lower case letters)
The main issue is that I have no clue how to perform a reliable system to generate and validate a security codes.
I feel like I should have a secret key stored on the server side, that would be necessary to generate a code, and I would have to find it back if a given string is a valid code.
Let's say secret is my private key.
The generation algorithm would be something like secret + whatever = generated code (where the + whatever operation remains to define).
But then how could I check a given string? string - whatever =? secret would be the solution (where - whatever is the reverses operation of + whatever).
Well, I actually have no clue of what whatever could (or should) be.
Do you have any advice or guidance ?
For the technical part, I will probably code this in JS (with a NodeJS server).
But as I'm talking about the concept of security code generation, any pseudo-code will do the job.
Generate a hash of the person's email address (capitalized) and make the code the first n-characters. So, for example, if your email address is TOUPYE#GMAIL.COM then the SHA-256 hash would be: 038122aedbf777b8c7c3aaed14ae7c08249a9d47f82f4455a0d667cacc57d383 so your code would be "038122". Generate a list of codes for each person/family. If someone has no email address use the telephone number. If they do not have a telephone, use their address.
Related
Is there a way knowing what hash-algorithm is used?
My question is grounded of that I've got an database from a customer with some users and passwords. I have no idea what the passwords are (so it's correctly stored in the database) and the customer would not like to give these passwords away (it's understandable)
I have access to the database and I know that the passwordhash is 60 characters long, but nothing else.
I basically want to create a new user (directly in the database if possible) with a temporary password so I can login to the system - but it's kind of impossible if I don't know how to create the password. Any thoughts?
The system is created in CodeIgniter but I don't know what authentification-method is used.
What data do the passwords contain? Do they contain only 0-9 and a-f, i.e. hex
values, or can they contain other data too? If you want to know the algorithm, it is crucial to answer to this question.
If they contain hex values only, 60*4 = 240 and there is no common algorithm
which gives a hash that is 240 bits long.
It has been suggested that the password contains salt, which might explain the
unusual length.
Why not ask the customer what has algorithm is used? It is understandable that
the customer doesn't want to give away these passwords, but there should be no
objection to giving away the hash algorithm.
Hi I am building an Internet website with Java and Spring framework. I believe my question is not technology or framework related.
I need to have links in user interface so that visitors can click and to see records. These links have the format of
http://mysite.com?id=number-id-or-random-unique-string
Not all records are allowed to view. For the ID parameter in the URL, I could use the database-generated number as the ID value and so I do not need to have additional programming. Or I could use unique random string (for example: jcTDjhdDUls) as the ID value (I have to program this part). Numbers allow curious people (with good or bad intentions) to EASILY guess and try other IDs. Unique random strings seems better in this regard.
However, no matter numbers or strings as the value for the ID, I have security check in the backend code to see whether a visitor is allowed to see a record. From this perspective, I am not sure what is the real benefit of having random string as the ID.
I hope to have input from experienced people. What design decision do you choose? Or other better ideas?
Thanks and regards.
You certainly can if you want to, but I would not go through the trouble to randomize the ID. This is at its root, "security through obscurity (STO)." Sometimes STO is useful, but in this case I don't think it is worth complicating and bloating the code and memory footprint. It's surprisingly easy to enumerate the valid IDs whether they're randomized or not, using a tool like Burp Suite. All the security controls that really matter should be implemented in the backend.
I'm going to use PHP in my example, but my question applies to any programming language.
Whenever I deal with forms that can be filled out by users who are not logged in (in other words, untrusted users), I do several things to make sure it is safe to store in the database:
Verify that all of the expected fields are present in $_POST (none were removed using a tool such as Firebug)
Verify that there are no unexpected fields in $_POST. This way, a field in the database doesn't accidentally get written over.
Verify that all of the expected fields are of the expected type (almost always "string"). This way, problems don't come up if a malicious user is tinkering with the code and adds "[]" to the end of a field name, thus making PHP consider the field to be an array and then performing checks on it as though it were a string.
Verify that all of the required fields were filled out.
Verify that all of the fields (both required and optional) were filled out correctly (for example, email addresses and phone numbers are in the expected format).
Related to the previous item, but worthy of being its own item: verify that fields that are dropdown menus were submitted with values that are actually in the dropdown menu. Again, a user could tinker with the code and change the dropdown menu to be anything they want.
Sanitize all fields just in case the user intentionally or unintentionally included malicious code.
I don't believe that any of the above things are overkill because, as I mentioned, the user filling out the form is not trusted.
When it comes to admin backends, however, I'm not sure all of those things are necessary. These are the things that I still consider to be necessary:
Verify that all of the required fields were filled out.
Verify that all of the fields (both required and optional) were filled out correctly (for example, email addresses and phone numbers are in the expected format).
Sanitize all fields just in case the user intentionally or unintentionally included malicious code.
I'm considering dropping the remaining items in order to save time and have less code (and, therefore, more readable code). Is that a reasonable thing to do or is it worthwhile to treat all forms equally regardless of whether or not they are being filled out by a trusted user?
These are the only two reasons I can think of for why it might be wise to treat all forms equally:
The trusted user's credentials might be found out by an untrusted user.
The trusted user's machine could be infected with malware that messes with forms. I have never heard of such malware and doubt that this is something to be really be worried about, but it is something to consider anyway.
Thanks!
Without knowing all the details, it's hard to say.
However, in general this feels like a situation where code re-use should be possible. In other words, it feels like this boiler-plate form validation shouldn't need to be re-written for each unique form. Instead, I would aim to create some reusable external class that could be used for any form.
You mentioned PHP and there are already lots of form validation classes available:
http://www.google.com/search?gcx=w&sourceid=chrome&ie=UTF-8&q=form+validation+php+class
Best of luck!
I am trying to create a ticket for Remote Assistance. Part of that requires creating a PassStub parameter. As of the documentation:
http://msdn.microsoft.com/en-us/library/cc240115(PROT.10).aspx
PassStub: The encrypted novice computer's password string. When the Remote
Assistance Connection String is sent as a file over e-mail, to provide additional security, a
password is used.<16>
In part 16 they detail how to create as PassStub.
In Windows XP and Windows Server 2003, when a password is used, it is encrypted using
PROV_RSA_FULL predefined Cryptographic provider with MD5 hashing and CALG_RC4, the RC4
stream encryption algorithm.
As PassStub looks like this in the file:
PassStub="LK#6Lh*gCmNDpj"
If you want to generate one yourself run msra.exe in Vista or run the Remote Assistance tool in WinXP.
The documentation says this stub is the result of the function CryptEncrypt with the key derived from the password and encrypted with the session id (Those are also in the ticket file).
The problem is that CryptEncrypt produces a binary output way larger than the 15 byte PassStub. Also the PassStub isn't encoding in any way I've seen before.
Some interesting things about the PassStub encoding. After doing statistical analysis the 3rd char is always a one of: !#$&()+-=#^. Only symbols seen everywhere are: *_ . Otherwise the valid characters are 0-9 a-z A-Z. There are a total of 75 valid characters and they are always 15 bytes.
Running msra.exe with the same password always generates a different PassStub, indicating that it is not a direct hash but includes the rasessionid as they say.
Another idea I've had is that it is not the direct result of CryptEncrypt, but a result of the rasessionid in the MD5 hash. In MS-RA (http://msdn.microsoft.com/en-us/library/cc240013(PROT.10).aspx). The "PassStub Novice" is simply hex encoded, and looks to be the right length. The problem is I have no idea how to go from any hash to way the PassStub looks like.
I am curious, have you already:
considered using ISAFEncrypt::EncryptString(bstrEncryptionkey, bstrInputString) as a higher-level alternative to doing all the dirty work directly with CryptEncrypt? (the tlb is in hlpsvc.exe)
looked inside c:\WINDOWS\pchealth\helpctr\Vendors\CN=Microsoft Corporation,L=Redmond,S=Washington,C=US\Remote Assistance\Escalation\Email\rcscreen9.htm (WinXP) to see what is going on when you pick the Save invitation as a file (Advanced) option and provide a password? (feel free to add alert() calls inside OnSave())
I'm implementing a password + password hint code I and want to prevent the user from making the password hint reveal the actual password right away.
Here are the scenario that I want to prevent:
Lets say that the password is: foobar123
Then the password hint can't be:
"foobar123"
"The password is: foobar123"
"f-o-o-b-a-r-1-2-3" (or any other x len separator)
"f00bar123" (replace o with zeros)
several questions:
Am I going overboard with this? Should I just let users pay the price for being security unaware?
Am I missing an obvious scenario that I need to prevent also?
Can each scenario be evaluated using regex? This is the most extendable method of adding future checks that I can think of.
I would simply give the user a fixed set of questions to choose from, to which they supply the answer. In this way you are never exposing user input values, only the user's selected value from your pre-canned list of choices. This would avoid your problem entirely.
Alternatively, if you have the user's email address, you could simply have a password reset that sends a link with an encoded key that allows a one-time password change. This way you need not provide a hint, simply a means of changing the password in response to one of these single-use tickets.
If your threat model makes password hints acceptable, I think you're going overboard with your meticulous password exposure prevention.
However, if your threat model doesn't make them acceptable, but you're being pressured into offering the feature, then be as fascist as you can.
Finally, don't limit people to canned password hints. They're extremely annoying. They imply that you know what is and isn't public knowledge in my life. Most of the sites I notice canned-only password hints on, offer hints that are all a matter of public record.
Good luck!
Personally, I say you are probably going overboard. But it somewhat depends on both the severity of compromised data (e.g. is this a web site to vote for Ms. High School or is it a web site for high-end auction house or is it a web access form for CIA?), the amount of users, and the likelihood that anyone would sue you for negligence in design after using bad hint and having their access compromised.
You can do the regex for the most dumb ones (e.g. take 6-character sub-strings of the password and do a match of those sub-strings in the hint), as well as character count for the smart ones. E.g. if the hint uses 60 to 80% of the characters in password (by count), reject it.
An even more nuanced solution is to count with position, e.g. count "o" only if it comes after "f". but this is probably overboard too.
Also consider non-hint solutions (multiple choices, non-verbal hints, e-mailable password change requests)
Does it need to be a hinting model?
The way I've done this in the past is to:
A- Have a security question.
B- Have a captcha.
C- Provide a new temporary password to an email on file only that must be changed on first use.
You can't prevent users from doing something dumb. No matter what protections you put in place, they will find a way to get around them. For example:
"321raboof backwards"
"foo and bar123"
"foobar (124 - 1)"
I don't believe there's a deterministic way to generate a hint, unless you're limiting passwords to something like birthdays or given names.
But they wouldn't be strong passwords would they?
Let the user suggest a hint - and pay the price for an obvious one.
Give plenty of advice that the hint shouldn't be obvious, but I think it must be up to the user to decide.
It's not your problem if they compromise the security of their account. Save on unnecessary coding and testing, and just don't worry about this feature!
I am about to change our password hint model to one with canned choices. To those who said it's the users own problem if they put a stupid question and answer I would mention that it become the problem of those who work for our help desk tech support. That's what we'e trying to avoid.