I need to use current time because later on, another program will need to know when I generated the pin and whats the username and password.
Summary:
Username + password + current time = pin [6 digits]
Reverse, generated pin, I need to know which particular, and check if its already pass 1 minute.
I am not asking for direct code, but I need to know the best, not say best, good way/algorithm for it. Thanks (btw, I am cpp beginner)
EDIT:
I am sorry for not making things clear. Actually, I dun need the OTP, after generated the pin, the other program will need to run like this: validate {username} {password} {pin}
999999 minutes, gives ~694 days, ~1.9 years. So if you used all the entropy available just for recording the current time, you'd cycle the value in less than 2 years.
And things will be much worse if you want to include the username and password, and avoid easy guessing.
With 6 decimal digits, you can store about 19 bits of data. So you'll have to make sure that you have strong anti-brute-force protection on your server end, otherwise it'll be trivial to try all possible combinations.
One-time passwords do not have internal decode-able structure, they are typically used in addition to a normal password to act as a second factor in authentication. Then can be based on the time as you are suggesting, but are not reversible - the other end also has the secret key, and can generate the possible list itself.
So, for example, as well as entering a username and (normal) password, the user enters the value from a token, which is generated as AES(secretkey, currentminute), and the server computes AES(secretkey, currentminute) and AES(secretkey, currentminute-1) etc, to compare the value against. It might also record which token matches, so that it records an estimate of the token's clock accuracy, which allows some drift of the token's clock, as long as it's used frequently enough. To work out how to best use the 19 bits you have in a 6-digit pin, you'll need someone who is a real cryptographer - as I would guess that taking a simple truncation might be in-secure.
Promoted my earlier comment to an answer, as an afterthought:
I'm pretty sure it is deceiving to call this 'otp'. OTP is purely random and secret.
What you describe is a simple hash.
You could
MD5(username+password_hash+(seconds_past_1970%60))
I'm sure besides using public key encryption instead of the password, this is more or less how RSA keys do it.
Edit Oh yes: it will be pretty trivial to generate 6 digits from the resulting hash :)
Related
In django user table password are encrypted automatically with a secure algorithm (pbkdf2_sha256) with salt and iterations. But what I don't understand is why the django password field shows the algorithm, iterations and salt in this format:
<algorithm>$<iterations>$<salt>$<hash>
I thought those information are secret and I want to show only the hash.
I thought those information are secret and I want to show only the hash.
It is secret in the sense that you should not expose this. But since a password can be hashed with different hashing algorithms that take a different number of iterations, and a different salt, you can not match the hashing with the password.
Indeed, when Django wants to check if the password matches, it will need to perform the exact same hashing (so the same algorithm, number of iterations and salt) to check if the two hashes are the same. Django thus needs this info to check the hash.
Note that here the salt is each time different, so by adding salt, the "search space" grows exponentially, and thus rainbow table attacks [wiki] are less successful. Furthermore as long as hashing is cheap in one way, but can only be determined through exhaustive search in the different direction, then hashing is a security measurement.
If one would not store the algorithm, number of iterations and salt per user, but simply store these things in a file, then we use the same algorithm with the same number of iterations and the same salt each time. In that case, a rainbow table attack can be more effective. By specifying random salt per record and with a , we let the "search space" grow exponentially with the length of the salt.
If the hashing algorithm is a one way function [wiki], then providing the parameters like the salt, algorithm and number of iterations will not suffice to calculate the function in reverse without exponential search, which is costly and easily scales beyond feasible with the current technology level.
I am making an application to secure barcodes so the patients at hospitals cant read them. But i want to hear your perspective on it.
First of all im making this program in C++.
My idea is to make a barcode and secure it for patients at hospital for a application which i am developing (secret sorry guys).
The way i am going to secure it is to get the following information about the patients.
Their unique ID nr (its possible in Denmark to do that)
Their room nr which they are staying at
Their Patient nr (the patients have a specific patient number)
The unique ID nr is containing 10 chars. The room nr contains 2 digits and the Patient nr contain 10 digits.
If I am predefining each chars and digits to random numbers and letters, and if I for example take 1 char from the ID nr and generate it to 5 chars in my secured code (or maybe after I have generated the new code I will secure it afterwards with a AES code or something), would that be a good way to secure the barcode, so the patient cant read the BarCode and get information of it?
The problem is that the patient must not scan the other patients barcode and retrieve information out of it, because that will be a big problem.
Please don't do what you are suggesting!
Instead, use a surrogate key (barcode) which is held securely in a database (and by that, I mean carefully check all relevant laws in your jurisdiction).
Don't try and be clever and 'encrypt' any info into the key. It will come back to bite you.
I am designing the primary key for storing product. I look around to find some insight how to design the ID as using auto increment is too boring. Do any one know that the code 'KB46279860I' on the below banknote meaning?
100 USD picture
I think that code is not just using auto-increment but some algorithm like check digit,etc.
Could any one give me some hints , Thanks!!
If you're not planning on showing the user your ID then auto-increment could save you processing time as it is handled by your database directly.
If you are planning on showing the ID to the user without showing the one in the database, you could consider using Hashids, or GUID or generating your own unique random value with a check digit. You can use Luhn or Damm's algorithm for check digit.
My users will in some cases be able to view a web version of a database table that stores data they've entered. For various reasons I need to include all the stored data, including a number of integer flags for each record that encapsulate adjacencies and so forth within the data (this is for speed and convenience at runtime). But rather than exposing them one-for-one in the webview, I'd like to have an obfuscated field that's just called "reserved" and contains a single unintelligible string representing those flags that I can easily encode and decode.
How can I do this efficiently in C++/Objective C?
Thanks!
Is it necessary that this field is exposed to the user visually, or just that it’s losslessly captured in the HTML content of the webview? If possible, can you include the flags as a hidden input element with each row, i.e., <input type=“hidden” …?
Why not convert each of the fields to hex, and append them as a string and save that value?
As long as you always append the strings in the same order, breaking them back apart and converting them back to numbers should be trivial.
Use symmetric encryption (example) to encode and decode the values. Of course, only you should know of the key.
Alternatively, Assymetric RSA is more powerfull encryption but is less efficient and is more complex to use.
Note: i am curios about the "various reasons" that require this design...
Multiply your flag integer by 7, add 3, and convert to base-36. To check if the resulting string is modified, convert back to base-2, and check if the result modulo 7 is still 3. If so, divide by 7 to get the flags. note that this is subject to replay attacks - users can copy any valid string in.
Just calculate a CRC-32 (or similar) and append it to your value. That will tell you, with a very high probability, if your value has been corrupted.
If a customer were "silly" (being polite here) enough to try and add, as an example, 4.6 items to their basket, what would you expect to see? or how would you deal with it. Obviously, we only deal with digital quantities (our hacksaw broke last week).
There seems to be a lot of inconsistence across the web.
Amazon Rounds down (4.6->4, 1.3->1)
FireBox Rounds (4.6->5, 1.3->1)
Ebuyer ignores the input (no error)
Expansys removes the item from your basket
I'm assuming some site will show an error
Which is the best solution
Add JavaScript verification that would remove non-numeric input while the user is typing in
Implement backward solution for the situation when JavaScript is off, either display an error message or round the value but then display a message saying "your input has been adjusted"
ADDED: Also be aware that the character that separates the fractional part from the integer one differs from country to country. In US I believe it is '.', in Europe it is usually ','. If your applications is targeted at customers in different countries with varying number representation, it would make sense to implement the support for both characters in your application logic. Otherwise some users will get format error messages without knowing why - non-techie people are often unaware of this format issue.
How about validating the user input and accepting only numeric characters?
One solution would be to bring the incorrect input to the user's attention so they can correct it. Rounding can be too much of an assumption depending on the context.
Displaying an error message next to the amount something like this: "I'm sorry, we cannot supply you with 4.6 items. Please enter a whole number." ...or something along those lines.
Another solution would be to avoid displaying error messages by restricting the input field to only allow valid input. ie If you don't want 4.6 items...only allow the user to be able to type 0-9. If the user can't enter incorrect input then there is never any reason to display an error message.
Assuming you're talking about a web app here, you can limit the characters allowed in the input box.
Alternatively, IMO you could use spinner (+/-) controls to change the quantity.
I believe tesco.com does this.
The best solution according to me would be
Customer enters: 4.6
Value changes to 5 after submitting (or if 4.4, round it to 4)
Notice is displayed telling the user that only integers are valid and that the system has roundedy "your" input (4.6) to 5
One solution would be to inform the user that their selection is invalid when they tab off the edit field that's allowed them to enter the fraction.
A lesser option would be to round (down, unless you're greedy to sell 1 extra item), or to reject the input completely.
The best solution is to prevent fractions in the first place by giving them a slider or spin control to select only whole numbers.
At the end it's always safer add server side check.
So if the input it's not an integer value:
I will redirect the user to the same form.
I will set the field with the floor value (4).
I will put on top of the field a message like"This field must be an integer value. May be did you want 4 pieces of this product?"
In my opinion if your product is an shopping system then it makes sense that primary goal is to sell some items. Usually customers want to perform as less actions as possible, so the system should predict what customer could possibly want when typing incorrect inputs.
Amazon Rounds down (4.6->4, 1.3->1) - the best for me, because everything after the decimal point can be destined to some other input;
FireBox Rounds (4.6->5, 1.3->1) - as for me I don't like when someone want to sell me more than I want to buy, so better 'floor' than 'round';
Ebuyer ignores the input (no error) - then you'll sell nothing and user needs to enter some values once again;
Expansys removes the item from your basket - terrible, now I need to search for the item in the shop once again;
I'm assuming some site will show an error. - not bad but required user to retype value;
I would implemented as Amazon plus informing user that input was not fully clear and asking him to recheck the value. So if the system guessed right then user need to change nothing but if he mistyped he'll see it immediately.
Also you could log all this kind of incidents and then perform an analysis, what user typed for the first time and what was the actual count he bought. Just for curiosity...
Well, you definitely should never round up. You should not ever bill for more materials than the customer requested, no matter how inane the request.