3 ms·

This isn't meant for a highly secure organization. This is meant for a mom and pop shop with limited inventory and limited employees. Most of his target audienc

This isn't meant for a highly secure organization. This is meant for a mom and pop shop with limited inventory and limited employees. Most of his target audience are very very small businesses, trying to save a buck on POS software. From his website: 26,000 ITEM LIMIT You may have noticed that it requires almost zero time to find any item in the stock table by the stock number. This is because all of the stock numbers are indexed and held in memory by the program. Unfortunately there is limited memory in DOS software to do this. The theoretical maximum would be 32,000 items but since some memory must also be used for other purposes the program becomes unstable with more than 26,000 items. The other consideration is that one of the reasons that this program is free is to help the small to medium business compete with the Wal-Marts of this world. With some exceptions once a retail business grows large enough to carry more than 26,000 different items then it is a Wal-Mart type large business and should be able to afford commercially produced POS software.

frankzinger 7y ago
26,000 ITEM LIMIT You may have noticed that it requires almost zero time to find any item in the stock table by the stock number. This is because all of the stock numbers are indexed and held in memory by the program. Unfortunately there is limited memory in DOS software to do this. The theoretical maximum would be 32,000 items but since some memory must also be used for other purposes the program becomes unstable with more than 26,000 items. The other consideration is that one of the reasons that this program is free is to help the small to medium business compete with the Wal-Marts of this world. With some exceptions once a retail business grows large enough to carry more than 26,000 different items then it is a Wal-Mart type large business and should be able to afford commercially produced POS software.
stakhanov 7y ago
That's not the point: A bookkeeping system has to have certain properties in order to be able to make it through a tax audit. For example, once a transaction is entered, there have to be certain guarantees that the transaction can't just be deleted or meddled with afterwards. In the pen-and-paper era this was accomplished using special writing instruments. If your books were kept with a pencil or pen with erasable ink, you'd be in big trouble. It sounds to me a bit like what the author is saying here is that, if the source code were to get out, then it would become common knowledge how to meddle with the accounting records using a hex editor and that, in turn, would be something that an expert witness in a court of law or a tax auditor would point out to attack the admissibility of the whole system. But that's kind of bad. If the records can be meddled with in a way that would be known if the source code were to get out, then they can probably also be meddled with without the source code being public knowledge (just harder to figure it out), and that is almost as bad: Security-by-obscurity is probably not a valid defense against that allegation if it were to come up in court. So, there should really be some crypto there instead.
- Crinus 7y ago
  The moment you enter into hex editing these records is the moment that you are into trouble anyway - assuming the software is trusted in the first place. In some countries it isn't really the POS that does the bookkeeping, but a special device is used that communicates with tax registry (or something, i'm not 100% sure on this). All the POS software does is tell the device what it was sold, the device registers it with the tax registry and gives back some sort of code string to be printed on the receipt. This also allows the receipt to be any type of paper (as opposed to the special triple-layered paper that was often used back in the day) and even if the device itself is tampered with, the information has already been sent to the tax registry. I think the author of this POS is mostly using this as an excuse to not release the source code, not for any practical reasons.
- Slartie 7y ago
  POS Developer here. What you describe is a so-called fiscalized POS system (at least in Germany we call them this way, not sure if there's a different English term). These must report the transactions in a cryptographically secured way to a fiscal authority. To do this, there are multiple concepts (of which some include hardware security devices, smart cards or non-erasable storage or similar, and some do rely on software-only solutions) and any country mandating the use of such systems finds a slightly different way in which they want it done. In addition to this mechanism that allows the fiscal authority to check the transactions on a specific POS for manipulation, fiscal requirements also often mandate much more, such as explicitly registering POS systems with the authority using serial numbers or hardware checksums, mandating the use of specific receipt layouts, or some kind of freeze of viable parts of the POS software which can then not be modified after approved once by the state (you can imagine how much love this kind of regulation gets from developers wanting to work under modern, agile principles...). However, not all countries mandate such things - many still accept POS systems that basically do nothing to prevent anyone from modifying transactions after the fact (although there is definitely a trend to more strict fiscal requirements globally). These non-fiscalized systems can try to make it hard to modify transactions if they want, and many do, but they cannot make this actually impossible without having some kind of external authority in play, which is why any effort of doing so will amount to some more or less elaborate kind of "security by obscurity".

frankzinger 7y ago

26,000 ITEM LIMIT You may have noticed that it requires almost zero time to find any item in the stock table by the stock number. This is because all of the stock numbers are indexed and held in memory by the program. Unfortunately there is limited memory in DOS software to do this. The theoretical maximum would be 32,000 items but since some memory must also be used for other purposes the program becomes unstable with more than 26,000 items. The other consideration is that one of the reasons that this program is free is to help the small to medium business compete with the Wal-Marts of this world. With some exceptions once a retail business grows large enough to carry more than 26,000 different items then it is a Wal-Mart type large business and should be able to afford commercially produced POS software.

stakhanov 7y ago

That's not the point: A bookkeeping system has to have certain properties in order to be able to make it through a tax audit. For example, once a transaction is entered, there have to be certain guarantees that the transaction can't just be deleted or meddled with afterwards. In the pen-and-paper era this was accomplished using special writing instruments. If your books were kept with a pencil or pen with erasable ink, you'd be in big trouble. It sounds to me a bit like what the author is saying here is that, if the source code were to get out, then it would become common knowledge how to meddle with the accounting records using a hex editor and that, in turn, would be something that an expert witness in a court of law or a tax auditor would point out to attack the admissibility of the whole system. But that's kind of bad. If the records can be meddled with in a way that would be known if the source code were to get out, then they can probably also be meddled with without the source code being public knowledge (just harder to figure it out), and that is almost as bad: Security-by-obscurity is probably not a valid defense against that allegation if it were to come up in court. So, there should really be some crypto there instead.

Crinus 7y ago
The moment you enter into hex editing these records is the moment that you are into trouble anyway - assuming the software is trusted in the first place. In some countries it isn't really the POS that does the bookkeeping, but a special device is used that communicates with tax registry (or something, i'm not 100% sure on this). All the POS software does is tell the device what it was sold, the device registers it with the tax registry and gives back some sort of code string to be printed on the receipt. This also allows the receipt to be any type of paper (as opposed to the special triple-layered paper that was often used back in the day) and even if the device itself is tampered with, the information has already been sent to the tax registry. I think the author of this POS is mostly using this as an excuse to not release the source code, not for any practical reasons.
Slartie 7y ago
POS Developer here. What you describe is a so-called fiscalized POS system (at least in Germany we call them this way, not sure if there's a different English term). These must report the transactions in a cryptographically secured way to a fiscal authority. To do this, there are multiple concepts (of which some include hardware security devices, smart cards or non-erasable storage or similar, and some do rely on software-only solutions) and any country mandating the use of such systems finds a slightly different way in which they want it done. In addition to this mechanism that allows the fiscal authority to check the transactions on a specific POS for manipulation, fiscal requirements also often mandate much more, such as explicitly registering POS systems with the authority using serial numbers or hardware checksums, mandating the use of specific receipt layouts, or some kind of freeze of viable parts of the POS software which can then not be modified after approved once by the state (you can imagine how much love this kind of regulation gets from developers wanting to work under modern, agile principles...). However, not all countries mandate such things - many still accept POS systems that basically do nothing to prevent anyone from modifying transactions after the fact (although there is definitely a trend to more strict fiscal requirements globally). These non-fiscalized systems can try to make it hard to modify transactions if they want, and many do, but they cannot make this actually impossible without having some kind of external authority in play, which is why any effort of doing so will amount to some more or less elaborate kind of "security by obscurity".