I am implementing Time based OTP (TOTP) for my network security course. The last time I gave presentation my instructor asked me "If you're going to share secret key by generating QR code and then letting the client(soft token) scan it, how are you sure that its safe ? " He meant that how the procedure of getting key from database and then making its QR code is safe ? If a third party have access to that web page then ? can third party know secret key without scanning code ?
I'm so confused from his questions.
Most probably the question was with generating the QR code, not really about the security of the shared secret itself (there is nothing you can do more about transferring the shared secret - you have to somehow share it).
What you have to be careful about when it comes to QR generation - do not use external services (like google chart) to generate the QR code, you have to do it with minimum external library use - ideally purely on the client side.
Here is an example https://github.com/token2/totp-toolset-local
Related
As the title states, I've gotten this email for both projects I've made public on Github. One is a landing page for a local business and the other is a CRUD app I have on the App Store; both of which are using Firebase as the backend.
Is the API key being visible on Github such a security risk?
I've done some research after following the instructions in the email to restrict my API and have heard that you cannot make web service requests with a restricted API key.
I just want to show my repos for the projects for the application process and obviously don't want anything bad to happen with them by doing so.
Aren't Firebase APIs meant to be public?
If so, is it just my database rules that need to be stronger/more verbose?
If any more context is needed, please let me know!
Cheers!
NOTE: I'm still very new to programming so a lot of this is over my head
For Firebase apiKey in a web app you are intended to make this key public, so you should ignore this email -- see: https://stackoverflow.com/a/37484053/771768
Hopefully Best practices for securely using API keys helps.
I'm uncertain as to what you're doing specifically that's resulting in the email but it is warranted.
Please be very careful with API keys.
As the name suggests, these are like keys in that they unlock access to stuff. With digital keys, the additional challenge is that, once obtained, infinite copies of the key may be distributed (and these are usable until the API key is revoked).
There are (often) other (complementary|alternative) ways to authenticate APIs but, as I think you've discovered, sometimes you are required to use API keys.
In the case where they're required, you should endeavor to use complementary authentication mechanisms too in order to try to mitigate overuse and you should continue to be very judicious in your publication of these keys.
I suspect you should not be including (any) keys (ever) in your GitHub repos.
One rule of thumb is that vendors (like Google) use API keys as a way to limit access to (often paid) resources. If the vendor is giving you a key, they're often (not always) using the key as a way to determine how to charge you for an API too. If you're giving the key to others, you're giving other people the possibility of potentially incurring charges on your behalf.
I don't wish to scare you but I would like you to leave this question being very cautious when using keys even if only this causes you to read up more on the consequences of using them.
I have a question on the limitations of cryptography. May seem like a stupid question. I apologise in advance.
This is for a client which I myself am trying to wrap my head around it.
The information will be encrypted and then encoded in an accessible format e.g. QR or barcode. Decryption is using the application our developers are creating. The problem is that the application would be offline majority of the time when it is in used as the users would be in areas that have either intermittent or poor reception. So to be able to decrypt it, the application has to have the private key present on the device itself, correct? Would this even be a good solution? Even the developers have concerns on having all the apps offline with the same private key present. Note that the application will be used by multiple groups.
Is there an alternative that I can explore that any of you can suggest where we don't have to store the private key but still manage to secure the information for offline use? So far I've look into DRM for restricting copying information but not sure how it would help. I'm also willing to look into other solutions for this.
The database holding the information would be updated when they have an internet connection. I'm only assuming on this part since I'm not handling this part of the project.
Please and thank you in advance for your advice.
Maybe not the right way but found a suitable path.
Using a combination of asymmetric key and symmetric key where the symmetric key is used to decrypt data on the offline device. Asymmetric is used to encrypt the data. The asymmetric keys is only exchange when the devices are in need to be sync'd. This would put the trust on the devices itself so I'm not worried on this.
This idea came from Sectigo - Why Automotive Key Fob Encryption Hacks Are Making Headlines?
First, I'm working on a Master student's project, the project is a Web Bank System and apply encryption algorithms on this system.
The first algorithm which is a new encryption algorithm designed by the student who requested my help is to encrypt the sensitive data (Credit Cards information) on the database.
The second algorithm (which is a modified AES algorithm) is to encrypt the messages between the customer of the bank and the admin of the bank system using a web chat room.
Of course, there is no problem with the first algorithm because I can apply it to encrypt the Credit Card information submitted by the user and save it on the database.
But, the problem is that the professor that supervising on this student project insisted to secure the messages sent across the network by the admin and customer that they are using the web chat room and these messages must be secured using the second algorithm (modified AES).
As you all know, if I just code the second algorithm in Javascript to encrypt the messages on the browser client machine then send those encrypted messages to the server, that means this algorithm will be available to anyone who opens this webpage because we all know that Javascript is an open client source.
So, no more talking, I just want to ask that:
How to apply any encryption algorithm to secure the data transfer between client machine and server machine by using web application (for example web chat application) without to be this algorithm an open source to any client machine?
ADyson's comment contains the best solution to solve this problem practically, but it sounds like the professor has added constraints that prevent you from employing a practical solution.
It is not possible to execute an encryption algorithm on a client machine and at the same time keep the encryption algorithm a secret from the person and machine running the algorithm. They can always inspect the code.
As far as I am aware this is not possible, because the client will have to be able to both encrypt and decrypt messages; it logically requires the client understanding the encryption algorithm.
The strength of an encryption mechanism comes from the difficulty of reversing an encrypted message to plaintext without the key, even if one knows the algorithm.
If knowing an encryption algorithm allows someone to decipher a message without the key, then the algorithm is weak.
I want to handle some confidential data in one of my web application. So that the data shouldn't able to read by the Developer or Database administrator.
We can easily hide the data from DB administrator by implementing some encryption technique. But still the developer can see the data since he only creating the decryption technique. I want only the end user should see his data.
I can't encrypt data using some algorithms like PBKDF2 or DB side encryption methods Like TDE & EKM because still I need to keep the encryption key somewhere. If I keep in server side or in db the developer can access and decrypt the data. If I keep it in client side, the user can't access the information from a separate machine.
So How to handle this situation? Thanks in advance.
You are heading the direction of Zero Knowledge Web Applications, such as implemented by SpiderOak (see also crypton). These applications typically work by deriving a key from the user's password using something like PBKDF2, and performing encryption/decryption on client side. However, there are a number of complexities to overcome to make it true zero-knowledge, and also to meet usability requirements. One could write an essay on this, but instead I suggest you start by reading the linked references. If you have any questions, let me know.
In a nutshell, the "more zero-knowledge" you want the system to be, the harder it is to realise without sacrificing usability (one example is overcoming the points made in Javascript Cryptography Considered Harmful). However, there are various tradeoffs you can make in order to make it sufficiently difficult to cheat without affecting usability too much.
I need to keep the encryption key somewhere
No you don't. The user only has to remember it. For convenience you could save it in the browser's local storage.
Some web applications, like Google Docs, store data generated by the users. Data that can only be read by its owner. Or maybe not?
As far as I know, this data is stored as is in a remote database. So, if anybody with enough privileges in the remote system (a sysadmin, for instance) can lurk my data, my privacy could get compromised.
What could be the best solution to store this data encrypted in a remote database and that only the data's owner could decrypt it? How to make this process transparent to the user? (You can't use the user's password as the key to encrypt his data, because you shouldn't know his password).
If encryption/decryption is performed on the server, there is no way you can make sure that the cleartext is not dumped somewhere in some log file or the like.
You need to do the encryption/decryption inside the browser using JavaScript/Java/ActiveX or whatever. As a user, you need to trust the client-side of the web service not to send back the info unencrypted to the server.
Carl
I think Carl, nailed it on the head, but I wanted to say that with any website, if you are providing it any confidential/personal/privileged information then you have to have a certain level of trust, and it is the responsibility of the service provider to establish this trust. This is one of those questions that has been asked many times, across the internet since it's inception, and it will only continue to grow until we all have our own SSL certs encoded on our fingerprint, and even then we will have to ask the question 'How do I know that the finger is still attached to the user?'.
Well, I'd consider a process similar to Amazons AWS. You authenticate with a private password that is not saved remotely. Just a hash is used to validate the user. Then you generate a certificate with one of the main and long-tested algorithms and provide this from a secure page. Then a public/private key algorithm can be used to encrypt things for the users.
But the main problem remains the same: If someone with enough privileges can access the data (say: hacked your server), you're lost. Given enough time and power, everything could be breaked. It's just a matter of time.
But I think algorithms and applications like GPG/PGP and similar are very well known and can be implemented in a way that secure web applications - and keep the usability at a score that the average user can handle.
edit I want to catch up with #Carl and Unkwntech and add their statement: If you don't trust the site itself, don't give private data away. That's even before someone hacks their servers... ;-)
Auron asked: How do you generate a key for the client to encrypt/decrypt the data? Where do you store this key?
Well, the key is usually derived from some password the user has chosen. You don't store it, you trust the user to remember it. What you can store is maybe some salt value associated to that user, to increase security against rainbow-table attacks for instance.
Crypto is hard to get right ;-) I would recommend to look at the source code for AxCrypt and for Xecrets' off-line client.
Carl
No, you can't use passwords, but you could use password hashes. However, Google Docs are all about sharing, so such a method would require storing a copy of the document for each user.