I've read about One Time Passwords on Stackoverflow, other websites, in RFC 6238 - TOTP and RFC 4226 - HOTP.
I understand OTPs are not stored in plaintext in Database, but when they are sent via SMS Gateways to the client's mobile. They have to be in plaintext.
So, can't a man in the middle, say a person at SMS Gateway, read those OTPs?
How do banks and other organizations do this securely?
GSM uses encryption in its signals. so it difficult to decode but if you know SIM CARD Details and To which BTS it latched and Hacker also in that BTS range then it is possible to see your SMS using description logic. It required time and knowledge to decript. So TOTP are 99.9% secure.
Lets Talk About Gateways
They can be inside Banks Local/VPN Network For Security Reason.
Can use SSL/TLS encryption to make secure communication from banking system to GSM Gateways.
Person at SMS GATEWAYS
yes they can see. but if they don't have who is the recipient or what is the text it is difficult to find, as in gateways flood of sms usually happens. Any way bank can have agreement with sms gateways for not to log OTP SMS in there system, so person at sms gateway can not see those sms.
Related
Hello anybody describe me. I am always confused .
what is difference between HTTPS, SSL and PCI compliance.
how HTTPS work ??
how SSL work ??
how PCI work ??
SSL
Definition: SSL (Secure Sockets Layer) is a security protocol commonly used in circumstances like E-Comm, with Verisign etc to protect personally identifiable information during web transactions, as well as other sensitive data like credit card numbers and logins. SSL certificates generally need to be bought and installed on your web server.
More reading here: https://www.globalsign.com/en/ssl-information-center/what-is-an-ssl-certificate/
HTTPS
Definition: HTTPS is HTTP + SSL certificate.
HTTPS (Hyper Text Transfer Protocol Secure) is the secure version of HTTP. The "S" implies that all data that is sent over the browser is encrypted.
Example: Google Searches
PCI
Definition: PCI DSS Compliance Payment Card Industry Data Security Standard is the global data security standard for credit card payments. I agree that it doesn't make sense to "implement PCL like SSL". PCI compliance governs everything from the hardware (card reader or point of sale) to your payment gateway. It's much easier to go with a payment processor that is already PCI compliant, as adhering to standards independently is probably not worth your time. Square has a basic guide here: https://squareup.com/guides/pci-compliance
SSL, which has since been replaced by Transport Layer Security (TLS), is basically a set of cryptography protocols to ensure private communication from a client endpoint (e.g. web browser) to a server. Apart from private communication, when properly implemented, it also includes mutual authentication of the client and server (i.e. the client verifies that it's communicating with the server it thinks it's communicating with and the server verifies that the client is really who they claim they are) and some kind of tamper resistance; these are to prevent man-in-the-middle attacks and provide a partial defense against replay attacks.
HTTPS just means that you're using HTTP over TLS or SSL.
As I describe in my comments, PCI standards are very different than either SSL or HTTPS. PCI standards are exactly that - a standard for data security, not a specific network or cryptography protocol.
Here is a description of what PCI compliance means (from the PCI Compliance Guide FAQ):
The Payment Card Industry Data Security Standard (PCI DSS) is a set of
security standards designed to ensure that ALL companies that accept,
process, store or transmit credit card information maintain a secure
environment.
It's very important to note that there's a lot more to PCI compliance (and to software security in general) than just secure data exchange. In fact, the FAQ I link to above addresses that specifically; in response to the question "Am I PCI compliant if I have an SSL certificate?" they say the following:
No. SSL certificates do not secure a web server from malicious attacks
or intrusions. High assurance SSL certificates provide the first tier
of customer security and reassurance... but there are other steps to
achieve PCI compliance.
Some examples of other things you have to consider for data security:
Do you store passwords and other sensitive data properly on your server (e.g. salting them, etc.)?
Do you have adequate network security (e.g. firewalls) in place? (Note that, as described in the book I link to below, even then you shouldn't assume that merely having a firewall is a complete defense against security problems).
Do you have adequate physical security in place? For example, how feasible would it be for someone to walk into your server room and gain access to the servers? Do you have to scan a badge to get in to the server room, and is access restricted to authorized employees?
Do you run code with least permissions?
Has code been reviewed and tested for common security bugs like buffer overruns and integer overflows?
There's an excellent book out there called 24 Deadly Sins of Software Security that describes common security bugs.
i'm developing an android app that must be PCI PA-DSS compliant, my question is about this requirement in the PA-DSS_v3-1 document
3.3.1 Use strong cryptography to render all payment application passwords unreadable during transmission.
let's say i have a "change your pasword" feature in my app that transmits the user's account password over a ssl/tls encrypted connection to the server. Is this encryption sufficient to comply to the requirement? do i need to implement some kind of encryption before sending it through ssl?
thank you.
The PCI standard can be vague at times and a little 'open ended', but from our experience, its quite OK as you have it.
SSL/TLS IS the encryption, just use it for your forgotten password feature and you'll be fine.
I am trying to send authentication requests from several spoofed mac addresses to the AP. When I ran wireshark, I was able to see authentication responses from the AP. But how is this possible as no probe requests packets have been sent from these spoofed mac addresses.
This looks like this is stateless. But from what I have read, I have understand, there are three states -
Unauthenticated, Unassociated
Authenticated, Unassociated
Authenticated, Associated
Simply, the answer is "Yes, it is possible to send authentication request packets without sending probe requests".
As far as I know, Probe Requests are only necessary to allow mobile devices to obtain information from the APs at will (i.e. instead of waiting for beacons).
I have a small device that contains a client program which communicates with a server over the internet. Pretty standard stuff.
I have a requirement that the server be able to authenticate messages coming from the device, meaning that all communications from the device be from the authentic client and not from some impostor. It's assumed that an attacker can reverse engineer the client and also load his own programs onto the device.
I'm questioning whether this is even possible. I could certainly load a client certificate into the client, but an attacker could get to this and use it himself. The cost of the device must remain low, so no fancy hardware tricks. Any ideas on how I could do this?
Depending on the device, and what kind of abuse you are talking about, you could use a scheme that needs some kind of activation. Like entering a master key into memory only - so its lost if power is lost - a technic used on some crypto cards.
A way to counter stolen devices could involve some kind of lease of keys that needs renewal on a regular basic by specifying a secret.
A way to counter an imitation/copy could be to works with a common state between the client and server that keeps changing. Like negotiating new encryption keys regularly.
We use a similar thing with our apps and web services. We call it ApiValidation where the client in each request to the service adds a header called ApiID which the server can decode to see if the client is authorized or not.
Can some please describe to me the SMTP authentication in broad terms keeping in mind the below.
When someone asks 'what authentication are you using?'
What are they referring to? Which variant of SMTP protocol like ESMTP and POP-before-SMTP?
How many variants are there? and within those protocols I am reading about things like Auth Mechanisms (Auth login, Auth plain, CRAM-MD 5) ?
Can someone shed some light at a broad level here?
There are many layers and many aspects here. There are multiple relevant ESMTP extensions and multiple authentication schemes.
How you connect affects which authentication scheme makes sense. Generally speaking, if you have an encrypted connection, plaintext passwords are unproblematic, because the connection-level encryption takes care of preventing eavesdropping.
If you don't have an encrypted connection, ideally you will not want to transfer the password in any form at all. There are various authentication schemes involving challenge-response mechanisms or session password exchange in order to authenticate securely even over an unencrypted channel.
POP-before-SMTP was at one time popular because there were no adequate standards for authenticating SMTP. These days, it should be considered merely historical, although there are probably still some sites using this mechanism. The idea is to defer authentication to the POP protocol, which requires user authentication anyway; then when the user has authenticated over POP, the SMTP port is also permitted from the same IP address for a limited time. Obviously, if the user doesn't have or want to use POP, this is cumbersome, and some users are on NAT so that the IP address seen by the remote server is not uniquely theirs, but once upon a time, this arrangement fit quite naturally into how people connected to the Internet via dial-up PPP using their own ISP's POP and SMTP services only.
These days, for new systems, the default should be to set up a separate encrypted and authenticated Mail Submission Agent port 587 in accordance with RFC 6409. Some systems run a traditional SMTP server on port 465 over an encrypted channel, but this should be considered a legacy arrangement.
See further http://en.wikipedia.org/wiki/SMTP_Authentication and http://en.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol both of which I relied on heavily for this write-up.