Would you be interested by the program described above?
Yes
 17%  [ 5 ]
No
 82%  [ 23 ]
Total Votes : 28

I am opening the way for something better, the CalcPay (or i'm considering naming it CalcScan or CalcuScan) Project, which will allow users to insert images of their promotional card's bar code to their calculator, and upon paying at a store, they must enter a user-set code which the user must enter to display the bar code, like the star bucks app system of paying with a phone. Thanks to womp womp's suggestion.

Examples of Community Support (a record):

Yes
9% [ 2 ]
No
90% [ 19 ]
Total Votes : 21
Very Happy
Can't someone maliciously view the image that you are storing the data in, or otherwise view the data storing the credit card?

You could encrypt the data, but then you are sitting there for like half an hour waiting for the image to load.
_iPhoenix_ wrote:
Can't someone maliciously view the image that you are storing the data in, or otherwise view the data storing the credit card?

You could encrypt the data, but then you are sitting there for like half an hour waiting for the image to load.


A credit card is confidential info, and i cannot tell you how i'm planning on protecting the user's private information. Thank You For Asking and I Hope That This Statement Will Stop Any Further Inquiries By Other Cemetech Users.

Editor's Note: Removed unnecessary bolding
Can't we just view the source of the program? That defeats the point.

Even if it is written in ICE or something, multiple (IIRC) decompilers are available. For many of the users on here, it would not be too hard to figure out how you are encrypting the data.

And besides, I never asked how you were encrypting it. I was merely telling you how this is not a good idea.
Credit cards generally work with magnetic strips, not barcodes, so you can't make a program to make your calc act like a credit card with a stock calculator. This program would make a little bit of sense with loyalty cards however. You could make something like Key Ring, assuming the resolution of the screen is good enough (which it might not be).
Also, this would work by users adding their cards into the program, which means that the actual release of the program doesn't contain any sensitive information, and besides, loyalty card bar codes aren't what I would consider to be dangerous to spread around.
He meant that it would be an issue if you were to figure out how the information was encoded in memory. However, any security algorithm where you only need to know how the program works to decode information is a bad security algorithm. It's not hard to reverse engineer a compiled output in most cases, so you can't rely on people not knowing how things work. I also doubt that anyone will trust your program to store anything sensitive unless they know how it works. Also, something that a calculator would be able to encode and decode in a short amount of time will probably be crackable by a computer relatively quickly.
The canonical phrasing of this is "security by obscurity is not security at all". If the security of a program depends on no one knowing how it works, it's inherently vulnerable to someone figuring out how it works. The strongest security (and the only acceptable security where personally identifiable, health, financial, and similarly sensitive information are concerned) is security where the algorithm is known, clear, and strong against any plausible attack.
KermMartian wrote:
The canonical phrasing of this is "security by obscurity is not security at all". If the security of a program depends on no one knowing how it works, it's inherently vulnerable to someone figuring out how it works. The strongest security (and the only acceptable security where personally identifiable, health, financial, and similarly sensitive information are concerned) is security where the algorithm is known, clear, and strong against any plausible attack.


That is why i'm stating that i'm not going to disclose the program's algorithim

mr womp womp wrote:
Credit cards generally work with magnetic strips, not barcodes, so you can't make a program to make your calc act like a credit card with a stock calculator. This program would make a little bit of sense with loyalty cards however. You could make something like Key Ring, assuming the resolution of the screen is good enough (which it might not be).
Also, this would work by users adding their cards into the program, which means that the actual release of the program doesn't contain any sensitive information, and besides, loyalty card bar codes aren't what I would consider to be dangerous to spread around.


This program isn't just credit card bar codes, which i'm saying can be put in just like apple pay achieves this. my program is also able to display regular bar codes like when you want to share a long link with someone without typing it in

Even if someone were to view the image, they wouldn't be able to do anything with it, because they cannot do anything with a credit card bar code image if they aren't a cashier in a store
coolcrab123 wrote:
KermMartian wrote:
The canonical phrasing of this is "security by obscurity is not security at all". If the security of a program depends on no one knowing how it works, it's inherently vulnerable to someone figuring out how it works. The strongest security (and the only acceptable security where personally identifiable, health, financial, and similarly sensitive information are concerned) is security where the algorithm is known, clear, and strong against any plausible attack.


That is why i'm stating that i'm not going to disclose the program's algorithim

Well, this concept was very common in the industry back in the day, when the internet was small and encryption was not commonplace. But nowadays, it's just a question of a short time until someone cracks a system that is just secured by obscurity. Even back then did they successfully crack obscured copy protection schemes, hardware dongles and secure storage.

Since I doubt anyone actually owning a credit card would use a calculator to store their credit card info in the first place, there should not be any serious danger to humanity, unless some kid typed their parent's info in and took the calculator to school...
Muessigb wrote:
coolcrab123 wrote:
KermMartian wrote:
The canonical phrasing of this is "security by obscurity is not security at all". If the security of a program depends on no one knowing how it works, it's inherently vulnerable to someone figuring out how it works. The strongest security (and the only acceptable security where personally identifiable, health, financial, and similarly sensitive information are concerned) is security where the algorithm is known, clear, and strong against any plausible attack.


That is why i'm stating that i'm not going to disclose the program's algorithim

Well, this concept was very common in the industry back in the day, when the internet was small and encryption was not commonplace. But nowadays, it's just a question of a short time until someone cracks a system that is just secured by obscurity. Even back then did they successfully crack obscured copy protection schemes, hardware dongles and secure storage.


This is merely impossible, due to the fact that the calculator cannot be hacked through online method, cannot be hacked physically, since it's in your possession, and cannot be hacked on site while in your possession, due to it not being logistically possible to make a hack in 2 minutes when you arent looking, use it, and transfer the bar code to another device. Idea about it...
coolcrab123 wrote:

This is merely impossible, due to the fact that the calculator cannot be hacked through online method, cannot be hacked physically, since it's in your possession, and cannot be hacked on site while in your possession, due to it not being logistically possible to make a hack in 2 minutes when you arent looking, use it, and transfer the bar code to another device. Idea about it...

You are taking a break, not looking at your calculator for a few minutes, someone heared about it and just takes the thing out. They could also exchange it for another one, if they really wanted to. Generally, there are many ways to gain physical access.

Also, what barcode are you even referring to?
I have not seen a credit card with one so far. They usually have a smartcard processor and a magnetic stripe. The stripe could, if someone really wanted to, be read out with a compatible reader and be stored on the calculator, but why would anyone do that?
How would you even transfer the encoded info into the EFTPOS terminal at checkout?
Muessigb wrote:
coolcrab123 wrote:

This is merely impossible, due to the fact that the calculator cannot be hacked through online method, cannot be hacked physically, since it's in your possession, and cannot be hacked on site while in your possession, due to it not being logistically possible to make a hack in 2 minutes when you arent looking, use it, and transfer the bar code to another device. Idea about it...

You are taking a break, not looking at your calculator for a few minutes, someone heared about it and just takes the thing out. They could also exchange it for another one, if they really wanted to. Generally, there are many ways to gain physical access.

Also, what barcode are you even referring to?
I have not seen a credit card with one so far. They usually have a smartcard processor and a magnetic stripe. The stripe could, if someone really wanted to, be read out with a compatible reader and be stored on the calculator, but why would anyone do that?
How would you even transfer the encoded info into the EFTPOS terminal at checkout?


Look up apple pay or see it on your phone, where apple is able to let the user pay with a credit card via bar code, you can screenshot it and transfer to a computer, where you will run convpng and put it into the program
coolcrab123 wrote:
Muessigb wrote:
coolcrab123 wrote:

This is merely impossible, due to the fact that the calculator cannot be hacked through online method, cannot be hacked physically, since it's in your possession, and cannot be hacked on site while in your possession, due to it not being logistically possible to make a hack in 2 minutes when you arent looking, use it, and transfer the bar code to another device. Idea about it...

You are taking a break, not looking at your calculator for a few minutes, someone heared about it and just takes the thing out. They could also exchange it for another one, if they really wanted to. Generally, there are many ways to gain physical access.

Also, what barcode are you even referring to?
I have not seen a credit card with one so far. They usually have a smartcard processor and a magnetic stripe. The stripe could, if someone really wanted to, be read out with a compatible reader and be stored on the calculator, but why would anyone do that?
How would you even transfer the encoded info into the EFTPOS terminal at checkout?


Look up apple pay or see it on your phone, where apple is able to let the user pay with a credit card via bar code, you can screenshot it and transfer to a computer, where you will run convpng and put it into the program

Apple Pay is using NFC for contactless payment. Chase however, appears to have a QR code based system:
https://9to5mac.com/2016/11/21/chase-pay-mobile-payment-service/

But still, it would be plainly stupid to not renew the QR code at a regular basis. Just like the session IDs for online logins, this QR cost must contain an expiry date.
Since we don't really use contactless payment or credit cards a whole lot here in Germany (I always pay in cash at the store and online I use wire or PayPal), I can't tell you how it exactly works since I never used it before myself, but this would be a huge flaw if it was not the case since an untrusted POS system could always just store the QR data to make recurring payments from your account.
Quote:
Look up apple pay or see it on your phone, where apple is able to let the user pay with a credit card via bar code, you can screenshot it and transfer to a computer, where you will run convpng and put it into the program
Or, you know, just use Apple pay on your phone. Razz

Look, I love your thinking-out-of-the-box ideas, but you're coming up with things that just aren't practical to have on a calculator.

Don't let this stop you though, you have a great mind, I'm sure you can think of something that will improve all our experiences on our calculators. Smile
I liked mr womp womp's idea of taking this concept and using it for store loyalty program cards. Those aren't particularly sensitive, they almost always use barcodes, and moreover, they use standard UPCs.
I didn’t manage to find the calc id project here - could someone point me to that please
coolcrab, I appreciate and love your out-of-the-box thinking with innovative ways of storing data on a calculator. However, there are a number of issues with this project, at least as far as usage for sensitive data goes (credit cards).

1. A calculator is generally not capable of encrypting the information you'd be providing in a secure enough way to be industry-acceptable (keep in mind that if you are designing an app like this you must meet industry standards or your app will not be approved for commercial use). Similarly, if a calculator can decrypt the data fast enough for this project to be feasible, a computer will make short work of it.

2. As a few other people have stated, security-through-obscurity is not the worst thing when used with a conjunction of other security methods, but when it's essentially the main security method, it's horrible. Keep in mind that people in general will not trust your program to keep their data safe unless they know that the encryption in secure, and in many cases, you will not become an approved digital-pay system unless you REVEAL your encryption methods to a gov't committee and it's verified to be industry standard. I mean, you could say "I'm not revealing my encryption methods to keep your data safe", and store them in plain text files and no-one would be the wiser. It's actually beneficial to be able to say "I'm using an industry-standard 512-bit encryption" so people know (or can research) that their data is actually safe.

3. Lastly, and most importantly, if you put out an app that stores user data and that data becomes compromised and results in information theft, YOU are legally liable. This is the part that's most important to fully understand the gravity of, and generally makes endeavours like this not worth the risk unless you plan to profit off this project, which would also make it harder to sell this. If your app's security is ineffective to stop someone from stealing a user's data you could be sued for a LOT of money, even if you don't sell this program.

Just bear these things in mind Smile
KermMartian wrote:
I liked mr womp womp's idea of taking this concept and using it for store loyalty program cards. Those aren't particularly sensitive, they almost always use barcodes, and moreover, they use standard UPCs.


I am thinking about this as well, im looking to program it in ICE, but, due to my lack of understanding in it, i am also looking for someone to inform me (I know this sounds like a stupid question but, the ice documentation has horrible descriptive language):
HOW AM I SUPPOSED TO MAKE AN APPVAR THAT I CAN USE TO STORE DATA, THEN HAVE THE PROGRAM READ THE DATA, CHANGE IT INTO A VARIABLE THAT IT CAN MANIPULATE, AND THEN STORE IT BACK TO THE APPVAR...
Do you have a background in programming in general? As in, any language? Or are you just starting out?
...
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 1 of 3
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement