The following vulnerabilities are found in voice biometrics:
Replay: The biggest concern is the replay attack. Hackers might attempt to gain unauthorized access to a voice authenticated system by playing back a pre-recorded voice sample from an authorized user. Need to implement proper anti-replay/ spoofing measures.
Voiceprint re-enrollment (Social Engineering): The malicious user claims to the contact center agent that they are unable to authenticate with their voice, and that their voiceprint needs to be re-enrolled. If the agent complies, a fraudster can be enrolled in the system and be provided with access to a legitimate account.
Brute Force attack: This attack consists of a fraudster calling the IVR or call center numerous times until their voice is mistakenly accepted by the voice biometric system as belonging to a legitimate account holder. Vulnerability testing conducted on deployed voice biometric systems indicates that the rate of a success of a brute force attack is betw…
Less prone to compromise: Contrary to PIN/ Passwords storages compromised and stolen and replayed, the voice prints can not be replayed. Thus a compromised voiceprint is unusable for account access.
Anti reversing: A voiceprint is a hashed string of numbers and characters that represent how a specific individual’s voice rates on the myriad of characteristics being measured Also, it’s not possible to reverse engineer it to recover someone’s voice.
Proactive detection of known fraudsters: Each time a fraudster speaks within an IVR or to a contact center agent, the fraudster leaves his/her voiceprint in the same way that our fingers leave fingerprints when we touch an object. This enables an organization to create and store voiceprints of known fraudsters.
Non guessable: A voice is unique to the individual. It can’t be guessed unlike PINs or passwords.
Cost effective: The cost of implementation is low because there is no special hardware required. A simple telephone or microphone …
Everyone know the what HSTS (HTTP Strict Transport Policy)
does- It instructs the browsers to load a website over HTTPS no matter what.
You cannot load a website on the http. When you hit a website, eg, http://example.com, the server returns
‘Strict-Transport-Security’ Header that tells that now onwards the website must
be loaded over https.
We know the issue related to redirecting a site from http to
https, the 302/ 301 redirects the site to its secure scheme by loading the https://expmale.com when user hits http://example.com . The issue here is the
response from the first request which loads on http can be modified and
contents can be replaced with some phishing ones. Still a large no. of websites
do this redirection, one classic example is American Express. When you try to
first time , it redirects you to https://www.americanexpress.com
The website first loads as http and then makes a 301
redirect and loads again over https. The below pic will mak…
Security ModeDescription Versions supported 1 No
Security. Device operates in promiscuous mode allowing any other Bluetooth
device to connect it v2.0
and earlier devices support it.
v2.1 and later devices support for backward compatibility. 2 Service
level enforced security. Security measures are established after the channel
is established. Supports Authentication, Authorization and Encryption. v2.0
and earlier devices support it.
v2.1 and later supports for backward compatibility . 3 Link
level enforced security. Security measures are established before the
channel is established. Supports authentication and encryption. v2.0
and earlier devices support it.
but v2.1 and later devices support for backward compatibility. 4 It
is a service level enforced security mode in which security procedures are
initiated after link setup. Uses SSP (Secure Sample Pairing) Mandatory
for communication between v2.1 and later BR/EDR devices.
XFS: Phishing-like attack. Where a legitimate looking page is iframed inside a malicious website.
XSS: Input validation, Output encoding
XFS: Frame-busting code, so that the page can't be framed inside other websites.
As a part of security assessment of cloud based apps/ infrastructure we always face a challenge in scanning the servers in the cloud. Few of them are: Obtaining/ managing credentials always an headacheNot ideal for cloud solutionsRequires target machines to be always online
The limitations of the scanners: Traditional infrastructure scanners such as Nessus are of not much useSometimes the scanners does not report vulnerabilities correctly due to many issues such as machines frequently go down while scan is in process, some firewall issues etc
We need a solution which is rather than we scanning the target servers, it resides on the server and keep doing the scanning and sends the report back to the organization periodically. And here comes the concept of 'Agent based clod scanning'.
The benefits are: Rather than targeting the remote servers in the traditional approach, the agents installed on the servers keep on doing the scans and sends the periodic reportsCan run offline and…
Among many authentication modes for accessing resources over cloud, such as traditional authentication such as credentials, or muti-factor authentication, such as hardware tokens; the biggest issue is that they can be stolen, or mimicked. The traditional solutions available in market are mimicable and not fool proof, the hardware tokens, passwords etc. are easy to compromise. Also, the traditional approach towards the authentication process- first authentication via user credentials then use of any other mode of authentication such as hardware token- increases the attack surface.
How about reversing the above approach- first people who can prove who they are (Biometric) only can access the Login page. This will decrease the risk significantly as the login page will be available to a very few set of people rather than whole bunch.
So the steps are:
Biometric authentication- adding ‘what- you- are- factor’
Raises the security bar to the highest level
Challenging the traditional way of …
So, how does PCI-DSS affects our web application security testing or what to make sure the application is compliant with PCI, while doing the security testing.
Here are few requirements which needs to be taken case while testing a web application which handles financial data such as credit card information. As the PCI guidelines itself maintains that the application must be tested on regular basis in "Requirement 11: Regularly test security systems and processes."
But what should really we look for? The requirement 11 is tied back to other requirements Requirement 6.:
11.2.1 Perform quarterly internal vulnerability scans and rescans as needed, until all “high-risk” vulnerabilities (as identified in Requirement 6.1) are resolved. Scans must be performed by qualified personnel.
11.2.3 Perform internal and external scans, and rescans as needed, after any significant change. Scans must be performed by qualified personnel.
11.3 Implement a methodology for penetration testing tha…
There could be some instances where in you need to scan your Android devices with scanners such as Nessus etc to look for insecure/ unnecessary ports, services and misconfigurations.
There are two types of scanning- unauthenticated scan and authenticated scan. Unauthenticated scans are preatty simple, just provide the IP of the target to be scanned, but in case of an authenticated scan which is more comprehensive, you need to have some valid account created on the target device. So, how to run an authenticated scan on Android device? We don't have any IS level account on it.
One way to accomplish this is to create an ssh server on the device. Once the server is installed, it is very basic to run ssh commands remotely such as we do using Putty.
The steps are following:
1. Go ahead and download, install an ssh server. ssh servers such as SSHDroid, SSHelper etc can be installed. They can be installed via Google Play.
One is here: