I want to select incoming calls based on user input. E.g. by matching the telephone number to the user input number. To get user input number I used Java.
What are the best hardwares supporting to this requirement. I guess this hardware should allow us to call API and get current caller number. Then we can do the selection part using Java. After that we can another API method ans allow that call to proceed.
Let me know about the suitable hardware for this.
You have a number of options depending on how your incoming calls are presented - if you are lucky enough that they are coming in to a PABX which has some form of computer telephony interface (CTI) then you just need to interface your Java app to the PABX (many Cisco, Avaya etc pABX's will support some form of CTI).
If your calls come in on a standard line to a standard phone today, then you can either replace the phone with a simple commercial PABX (if you have the budget) or you can create your own PABX using one of the open source options and some line cards - see the answer to this question for a link to an example line card for the open source Asterix PABX:
https://stackoverflow.com/a/18220055/334402
If you have the option of a hosted VoIP 'telephone line' then it would be worth contacting your provider as they may provide hosted CTI options, saving you the need to get dedicated hardware.
Related
I am currently writing a firmware for an embedded device which acts as an human-machine-interface in an (aftermarket) automobile environment.
The device has got a service menu which shall only be accessible to specific personnel, which is secured by a device specific pin-code, which is generated randomly in production, burned on the device and stored in a database for the personnel to retrieve. Within the service menu, the user is e.g. able to manually change states and also overwrite limits for regulation functions etc.
However it might be necessary for any user to get to that menu in an error case, e.g. if they get stuck in a remote place and have a faulty sensor or whatever. Therefore I would like to create a kind of single-sign-in for the devices. My idea is, that the device creates a code and displays it to the user. The user then calls the service team which can create a pin valid for this device in this current state (the code displayed).
I don't want it to be too easy to figure out, so that anybody will be able to crack the algorithm of code generation. I cannot use any online functionality, as the users - as mentioned - may be in a remote place.
I was thinking about creating a table of random numbers and implementing it in the firmware (like 1-10k of pins and the device displays an index and the service teams just looks up the pin for that index) But I feel like there is a better solution to that problem.
My question:
What is a safe algorithm to compute a 4 digit (1000 - 9999) pin-code based on a random number (~6 digits hexadecimal) and (optionally) a 6 byte large serialnumber?
I am conducting a survey using Voice with Twilio. Part of that survey is to let the user give a voice feedback so i used Record at first. That was exactly what i needed since i could get the mp3 + the transcription. Problem is : i can't set the language to French so my transcription come in french, instead it is recorded and transcribed as english even though i speak french.
So i decided to switch and use the Gather with the speech option which works quite well, the text comes back in french, but using that option, i can't get the mp3.
So i decided that i would record the entire call, and use Gather which would have solved my problem, except you only get to set the record parameter to true when you initiate the call (outgoing call). My survey will be taken by incoming call 95% of the time..
I there any way to achieve this without having to use Record and use another API to do the transcription ?
Twilio developer evangelist here.
I'm afraid, in the situation you are in, where you need the mp3s and French transcription, then I can only recommend using <Record> and a third party transcription service. <Gather> with input type speech just doesn't support this kind of recording yet.
I am currently developping a windows application who test railroad equipments to find any defaults.
Utility A => OK
Utility B => NOK
...
This application will check the given equipment and generate a report.
This report needs to be written once, and no further modifications are allowed since this file can be used as working proof for the equipment.
My first idea was ta use pdf files (haru lib looks great), but pdf can also be modified.
I told myself that I could obsfuscate the report, and implement a homemade reader inside my application, but whatever way I store it, the file would always be possibly accessed and modified right?
So I'm running out of ideas.
Sorry if my approach and my problem appear naive but it's an intership.
Thanks for any help.
Edit: I could also add checksums for files after I generated them, and keep a "checksums record file", and implement a checksums comparison tool for verification? just thought about this.
I believe the answer to your question is to use any format whatosever, and use a digital signature anybody can verify, e.g., create a gnupg, get that key signed by the people who require to check your documents, upload it to one of the key servers, and use it to sign the documents. You can publish the documents, and have a link to your public key available for verification; for critical cases someone verifying must be trust your signature (i.e., trust somebody who signed your key).
People's lives depend on the state of train inspections. Therefore, I find it hard to believe that someone expects you to solve this problem only using free-as-in-beer components.
Adobe supports a strong digital signature model. If you buy into their technology base, you can create PDF's that are digitally signed, and are therefore tamper-evident, as the consumer can check for the signature.
You can, as someone else pointed out, use GNUpg, or for that matter OpenSSL, to implement your own signature scheme, but railroad regulators are somewhat less likely to figure out how to work with it.
I would store reports in an encrypted/protected datastore.
When a user accesses a report (requests a copy, the original is of course always in the database and cannot be modified), it includes the text "Report #XXXXX". If you want to validate the report, retrive a new copy from the system using the Report ID.
I was considering the various options that i have when i want to protect a generic chunk of data to apply this principles to the distribution of a generic application.
Encryption doesn't make sense, it's like giving something unusable for the user or i have to give both the encrypted file and the key do decrypt it which make even less sense.
Generating entropy does not make sense because this process will only re-arrange the data in other way without breaking the business logic of the application.
Wrapping my application in an executable that requires a password to the user, my real application and my wrapper are double-linked and if my wrapper does not gives a green light my application will not run.
Web based distribution like the popular "Steam" service with a customized compilation for every user based on some login/ID verification.
What are the other options? I know that this will not end up with a definitive solution but at least i want to avoid the user to just redistribute my application with a simple copy and paste and i want to have at least a small edge over the software distribution system.
The usual way of doing this is to encrypt the data using some piece of information that is already on the user's system as the key; the data is then keyed to that system. For instance, on Mac OS X you can get the system serial serial number with a library call. Sun systems have a gethostid() library call that makes this trivial. An alternative that works on dumb systems cough Winders cough is to use the MAC address of an ethernet interface, or something like that.
It can be tricky, you typically have to write a little program that will grovel around in the system and generate a key, and then have the customer email this key to you, or at least OK the program to email the key to you. You can then encrypt the protected data using the key information you got back, and have the customer download it. It is possible to add this entire transaction to your application installer, if the size of the data blob is reasonable.
I'm working on a wxWidgets GUI application that allows the user to upload files to an FTP server and a pair of username/password is required to access the FTP server.
As far as I know, STL strings or even char* strings are visible to end user even the program is compiled already, using hex editors or maybe string extractors like Sysinternals String Utility.
So, is there a safe/secure way to store sensitive informations inside a C++ application?
PS. I cannot use .NET for this application.
This is actually independent of the programming language used.
FTP is a protocol that transfers its password in plain text. No amount of obfuscation will change that, and an attacker can easily intercept the password as it is transmitted.
And no amount of obfuscation, no matter the protocol used, will change the fact that your application has to be able to decode that password. Any attacker with access to the application binary can reverse-engineer that decoding, yielding the password.
Once you start looking at secure protocols (like SFTP), you also get the infrastructure for secure authentication (e.g. public/private key) when looking at automated access.
Even then you are placing the responsibility of not making that key file accessable to anyone else on the file system, which - depending on the operating system and overall setup - might not be enough.
But since we're talking about an interactive application, the simplest way is to not make the authentication automatic at all, but to query the user for username and password. After all, he should know, shouldn't he?
Edit: Extending on the excellent comment by Kate Gregory, in case that users share a common "technical" (or anonymous) account accessing your server, files uploaded by your app should not be visible on the server before some kind of filtering was done by you. The common way to do this is having an "upload" directory where files can be uploaded to, but not be downloaded from. If you do not take these precautions, people will use your FTP server as turntable for all kind of illegal file sharing, and you will be the one held legally responsible for that.
I'm not sure if that is possible at all, and if, than not easy. If the password is embedded and your program can read it, everybody with enough knowledge should be able to do.
You can improve security against lowlevel attempts (like hexeditor etc.) by encrypting or obfuscating (eg two passwords which generate the real password by XOR at runtime and only at the moment you need it).
But this is no protection against serious attacks by experienced people, which might decompile you program or debug it (well, there are ways to detect that, but it's like cold-war - mutual arms race of debugging-techniques against runtime-detection of these).
edit: If one knows an good way with an acceptable amount of work to protect the data (in c++ and without gigantic and/or expensive frameworks), please correct me. I would be interested in that information.
While it's true that you cannot defend against someone who decompiles your code and figures out what you're doing, you can obscure the password a little bit so that it isn't in plain text inside the code. You don't need to do a true encryption, just anything where you know the secret. For example, reverse it, rot13 it, or interleave two literal strings such as "pswr" and "asod". Or use individual character variables (that are not initialized all together in the same place) and use numbers to set them (ascii) rather than having 'a' in your code.
In your place, I would feel that snooping the traffic to the FTP server is less work than decompiling your app and reading what the code does with the literal strings. You only need to defeat the person who opens the hex and sees the strings that are easily recognized as an ID and password. A littel obscuring will go a long way in that case.
As the others said, storing a password is never really save but if you insist you can use cryptlib for encryption and decryption.
Just a raw idea for you to consider.
Calculate the md5 or SHA-2 of your password and store it in the executable.
Then do the same for input username/password and compare with stored value.
Simple and straightforward.
http://en.wikipedia.org/wiki/MD5
http://en.wikipedia.org/wiki/SHA-2