Tag Info

New answers tagged

2

I'm answering my own questions but for future seekers, I found this great article: http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication. Maybe I didn't explain my question well but this was the answer I was looking for.


3

You cannot trust the client, ever. A malicious user may abuse legitimate client software (theirs, or someone else's) An attacker may reverse engineer enough of the API to pretend to be a legitimate client Instead of trusting the client, work to ensure that the client's input is trustworthy. input validation input sanitization schema compliance velocity ...


3

I have not yet fully explored the spec. But: U2F is not using an OTP. It is really about site authentication and using possession of a private key as a factor. Time-bound OTP systems do an excellent job of combating phishing (stealing credentials) because they are hard to steal. U2F is really meant to combat MiTM attacks. Brute-force attacks would not ...


2

You are relying on "security through obscurity", and implementing this type of security is never a good idea. You can create a vastly more secure and easier solution by implementing SSL (or TLS) on your solution. Here is a very good tutorial on Stunnel: you install stunnel create custom certificates encrypt everything transparently Using stunnel you can ...


7

U2F is capable of using an encrypted channel using public key crypto to ensure ONLY the right server can get the one time token. This means plugging it in when on a phishing site means nothing happens, they can't get into your account. Instead they have to rely on technical attacks like XSS and local malware. It is supposed to be able to hide the fact that ...


1

Before I give my answer, lets first go over the subject of HMAC. Hash-based message authentication code (or HMAC) is a mechanism for calculating a message authentication code involving a hash function in combination with a secret key. This can be used to verify the integrity and authenticity of a a message. Now HMAC authentication guarantees the ...


0

Looked around a little, and while most of this is over my head This PDF seems to be closely related to what you are asking. Hope it helps :)


2

First make sure nobody can abuse your codes. This may be even more harmfull than you not being able to login for a short time. So encrypt your phone and your external SD card if data is stored there. This requires that you use a PIN or password to use the phone. So nobody can use Authenticator without knowing that PIN. Don't use 0000 or 1234 but something ...


0

It's probably too late for some sites, but I would suggest taking a screenshot of any QR codes and saving that somewhere secure. That may mean print them and put them in a fireproof box. That will allow you to re-scan them at a later date. If you have that option on any sites, I recommend you do it. A similar option is to scan the QR code with Zxing ...


1

Be careful, you should not confuse keys used for encryption/decryption and keys used for signature, since there usage is different. So the key couple A-pub/A-priv is used for signature only, while the key couple B-pub/B-priv is used for encryption only. Be also careful that you should sign the ciphertext and not the plaintext, otherwise having the hash of ...


0

To answer your questions: 1) How do you handle a situation with a compromised token secret which is shared between a client and the server? Add an expiry date to your token. Make the sure the token cannot be used after the expiry time. But this doesn't prevent unauthorized access within the token's expiry period. So, to overcome this problem you can ...


0

The use of encrypted OAuth tokens is good approach to satisfying the security requirements in RFC-6749 section 10. Encrypted OAuth tokens are in common use, Facebook is a good example. OAuth tokens expire based on the expires_in parameter. Which means that a given token would be valid for a short time after the user logs out, which is very low risk issue ...


0

I can't comment yet, so I will post an answer. I can think of two things that they could do: Run a list of bad passwords through their hashes and see how many correspond to their database of password hashes, then count and rank them. Reverse engineer a sample set of their password hashes(why devote too much time to this?) and aggregate data on the brute ...


2

Your first link says what the source is: This list is from files containing stolen passwords posted online during the previous year. In a perfect world this would not happen. Not only would everyone salt and hash their passwords with an expensive algorithm, security would also be good enough that password lists won't get stolen. Unfortunately the world ...


1

While "reputable" websites may do this, there are just as many that do not securely store them and get compromised. Compromised password databases are available, and if you acquire them, you can construct such a list as the one that SplashData has constructed.


1

Robert - I recently was faced with the same issue. Wireshark does not decode SSL over EAP. What you can do is fake Wireshark out and take the entire ssl conversation and build it into a pseudo tcp session with the SSL data from the original eap packets and retransmit the frames. I used Python raw sockets to generate the tcp session and then capture the ...


1

An RSA token might be another option. This requires the user to enter an OTP which is displayed on the RSA token. Works well but is not inexpensive.


1

In addition to sebastians answer you might also consider not using yubicos backend server but to run your own system, so that the authentication request is not forwarded to yubico but handled on your own system or within your own (your customers) subnet. Alas, you need to install/run such a backend system. Yubico themself provide an authentication server but ...


2

To specifically address the scenario, Facebook doesn't need to wait until a user logs in to capture an OAuth token. Since you're trusting Facebook as your authentication provider, they can generate a valid OAuth token for any user in their system anytime they please. Given that, there are three potentially correct answers here. This is not a threat, ...


2

I would then suggest Yubikey ( http://www.yubico.com ). Yubikey is a OTP hardware token that does pretend to be a keyboard (Thus requiring NO extra software installation), and then sends a 128 bit encrypted secret to the server. The tokens are fully programmable by the administrator, and its possible to use the token in a variety of ways. You could either ...


1

The CryptoStick uses the Web Cryptography API to expose a keys to the browser. Its likely that the proposed USB security token product product would use a similar technique. CryptoStick is open source, so it is easy for 3rd parties to verify it's security. The 2-factor authentication that I use regularly is Google Authenticator, which makes it very easy ...


1

You are asking "what's bad about accepting (but not otherwise enabling) get based authentication?" The answer: it's a bad practice that may eventually lead to a vulnerability, but it doesn't directly create a vulnerability. For a vulnerability to exist, it must be exploitable in some way, and it must grant the attacker something they don't already have. In ...


-1

If login form is vulnerable to CSRF (no matter POST or GET), this is unsecure and known type of forgery: "login CSRF" http://en.wikipedia.org/wiki/Cross-site_request_forgery#Forging_login_requests related question: How to protect against login CSRF?


1

So I hope I do not make myself look like a idiot but I will try to help explain this from my understanding of it. I should note, this is not my full time job so please be kind if I have something really off:) These protocols, and I believe eap is a protocol, peap is protected eap, so it is probably the same protocol with additional encryption, are used to ...


0

The analogue of PPP in the EAP world is 802.1x or EAPoL (EAP over LAN). It is a very basic multicast protocol that sits atop Ethernet frames and which is only available on the interface itself. From that point on, it is up to the Authenticator (more commonly known as the Access Point or NAS) to propagate the authentication information to some higher layer ...


2

Question 1: this is not considered secure for a number of reasons: The password can be seen on the URL The password can be seen on browser history All the passwords will be on server logs If the user logs on the site, and there's a link pointing to an external site, and the user clicks it, the password is leaked Spyware with URL monitoring will be able to ...


0

It does work by either having a meta refresh, or a JavaScript, that continually send request to hold your session alive. Basically, it works by having a session identifier, that is a random string. This session identifier might be valid for lets say 3 minutes. Each minute, that webpage will either execute JavaScript code, or do a meta refresh, causing the ...


0

I guess you want to enroll users by POSTing CSRs. There is already enrollment schemes builtin browsers so you dont have to POST CSR's. Those enrollment schemes will also automatically install the client certificate in the browser store, so Everything is done in one shot. Here you have Everything to get started: ...


4

Redirection the user after a successful login is common in the most webapps. For instance when the user try to access the dashboard directly within its url, the system keeps the requested url and brings the user to the login page, after user signed in he is redirected to the dashboard not the homepage or something.


1

You fix the typo in the url https://aws.amazon.com/forms/aws-mfa-support/ (notice the 'r' in 'forms' that was previously missing


2

Probabilistic or statistical authentication are probably the best fit, the alternative to deterministic authentication. (Though technically, there's a degree of probability involved when password hashes are used, rather than plaintext passwords, let's just ignore that for now.) Biometric implies a probabilistic system, but the converse is not true, e.g. ...


1

Anyone who is watching network traffic on my web app can see the token (in headers) and can copy it and form their own malicious calls. That is correct. This is why you would want to make sure you use a secure connection (HTTPS in the URL), which will prevent man in the middle attacks.


4

Your understanding is already pretty good. As you say, there are a variety of EAP protocols: LEAP, PEAP, EAP-FAST, EAP-TLS, etc. Each one works differently, but they all do the same thing: authenticate a user before allowing them access to a wireless network. You could call EAP a protocol, or you could call it a framework of protocols, where each variant ...


1

Depending on metrics such as the false acceptance rate and the false rejection rate of your authentication system, you can set a similarity percentage for which your biometric authentication is acceptable. Also, I don't think you can speak of passwords regarding voice authentication because it relies on an inherence factor as you can see on Wikipedia.


0

Not really a detailed description, but from what I understood, I have few questions :) In step 1: The Diffie-Hellman key exchange is vulnerable to a man-in-the-middle attack. Even if it is running inside a secure connection TLS/SSL. The only way to avoid that is to use PKI certificates. In step 2: How do you plan to recycle the secure token. I mean for how ...


1

The YubiKey NEO is a unique One-Time Authentication device which combines the functionality of a YubiKey Hardware Authentication device with the extended capabilities of a smart card, without requiring additional drivers or software. The YubiKey NEO has 3 major elements - the first is the YubiKey element, which allows the YubiKey to be used as a ...


1

I guess you use SSH-keys as authentication? Reauthentication and key exchanges happens all the time during the SSH protocol, so having a Active session is secure enough. Another thing is confirmation, eg, you want that the user really wants to commit a action that might be irreversible. Lets say deleting something. To solve this problem, I would suggest ...


0

If you don't want to share keys AND you use asymmetric keys then you can key each server separately and have each server set a different iss (issuer) claim. Then the recipient of the JWT can "look up" the appropriate public key based on the iss claim. Our lookup was basically a config file that mapped the iss value to a file system location of the public ...


2

This is called federated authentication. In the enterprise world, this is often accomplished with Kerberos (for non-web based systems) or SAML (for web-based systems.) In the non-enterprise world, far and away the most popular federation framework is OAuth 2.0. There is an extension to OAuth 2 called OpenID Connect (much different from the older OpenID ...


4

Could there be some miscommunication between you and the IT department head? As Xander had already pointed out, such a scheme does not work, and I would even add that it is ridiculous. In order to authenticate a user, a database lookup has to be performed on the login email address in order to retrieve the corresponding hash used for comparison: SELECT hash ...


9

As far as I can tell, this scheme doesn't make any sense. As you've noted, you still need to store the plaintext email address for the user, so there isn't any significant security benefit to using the plaintext email and email + password + salt hash vs just using plaintext email and password + salt hash. As I'm sure you've already noted, without the ...


1

"Pass the Hash" is a combined weakness of windows and NTLM, which can be exploited in a corporate environment if one administrator account with the same password is used for multiple computers, to gain access to all of those computers. From the Wikipedia NTLM article: The NTLM protocol uses one or both of two hashed password values, both of which are ...


6

The vulnerability is in the fact that the application enforces second-factor auth verification client-side. That is, the service itself does not require two-factor authentication, ever. But it is willing to process two-factor authentication if requested, and if the client app learns that account has two-factor enabled, then the app will attempt ...


2

as the website service panopticlick puts it "How unique and trackable is your browser?" there are many things that especially via scripting can be found out about your machine. This uniqueness estimation can include browser type browser version geometrics (screen size) average cpu usage / calculation power via script trial fonts (are a especially neat way ...


1

There are number of different ways that this can be accomplished. IP Addresses Typically, most host machines stay within a family of IP addresses. These addresses are assigned to your ISP, who in turn, assigns you an IP address when you purchase a subscription. If you login to your account from a different block of IP addresses, then they may know you ...


1

The biggest (and only) problem of password based authentication is that its strength is set by the user, and there is a strength-usability tradeoff. In theory, passwords have lots of great properties for an user: they are hard to obtain from third parties by force, you don't leak them everywhere like biometric data, they can be stored as hashes unlike ...


0

You are writing "keypass" but tagged your question "keepass". Hm, so are you talking of a password safe? Or are you talking of an SSH key to login to an ssh server? The ssh pubkey mechanism usually stores your private key in a file protected by a passphrase. This file could be copied and stolen and brute forced. This second factor (the ssh key file) can be ...


1

A keyfile is an element of a PKI. I mean it is heavy to manage and is intended to be used for a long time period and and be deployed on a large infrastructure whereas an OTP, by definition, is useful for one session only and it is somehow a lightweight but robust solution for simple lightweight applications because as soon as someone finds your OTP it is no ...


1

Its an improvement in having a strong windows account password (for online use) and a user-friendly device access code for offline. A big complaint about windows 8 is having to tie it to an online email account. Device access passwords are entered far more frequently than internet account passwords, and aren't open to as many threats. Additionally you can't ...


2

Why not just use an existing token-based authentication method like Kerberos and build off of it? So the user authenticates normally and receives a kerberos token. Then, you go to the API server, say "Hey I got this token!" The API server verifies it, and sends a copy of the encrypted data to the user, who can decrypt the keys on their machine? Seems ...



Top 50 recent answers are included