Tag Info

New answers tagged

0

A strong authentication mechanism that is easy for the user and provides reasonable assurance would be to stand up a CA that is not trusted by anyone other than your application. Issue each user a certificate with their UPN as the only entry in the SAN extension. Configure your application to authenticate the user via their certificate, and instruct each ...


2

It would not take away any security. Simple, Easy enter pins would simply auto-OK or auto-ENTER when 4 digits have been entered - just like iPhone. However, it would still mean that incorrect attempts are counted and at too many attempts the device is locked and require online authentication via google account. The implications "Easy Enter" could have, is ...


2

Like @user2313067 pointed, this problem is happening probably because the clock of your server is with wrong time. Google Authenticator is an implementation of OTP (One-time password) and it is based on a private seed and on time to check if the code you are entering is correct.


0

Leaks of server private keys probably do happen. But they don't get as much publicity. When a password database has leaked, many sites decide to force users to change their password. Obviously this generates more publicity than if the site silently replace their secret key without forcing users to change their password. Depending on your point of view, this ...


0

There are also "hardened" or "locked-down" systems where it is impossible to remove keys from the server - the keys need to be generated & stored elsewhere, and the server only allows a small whitelist of programs to use them after it imports them. Even if one does obtain the key, they should also be password-protected, and obtaining that password ...


2

For best security, the private key should be held in an HSM (or Smart Card implementing a minimal HSM). It is hard to extract the private key from that, especially remotely, except for a bug or backdoor in the configuration or implementation of the HSM. That's because all good signature (resp. encryption) algorithms have the property that no matter how many ...


1

In SSH public-key authentication, there are two pairs of keys involved. The first pair is maintained by each user who is trying to authenticate to the server. The private key for each user is maintained on the user's personal workstation or other client system, not the server to which the connection is being made. Also, the public key of each user is ...


1

You can use Apache's mod_ssl to authenticate against client certificates. The example is from cacert.org, but you can create your own CA to accomplish the same goal.


0

If deauth is only used to capture handshake then its no big deal that it is possible because if an attacker listens in on the com he will capture the handshake within 1 or 2 days anyway. This is why it is important to have 13 char password because that would take several billion years to crack if it was captured anyway.


1

Since money is the issue for you, I'll post this link: https://letsencrypt.org/2014/11/18/announcing-lets-encrypt.html The EFF, Mozilla, and other organizations have teamed up to create a free CA. It's designed for people in your exact situation. The downside is that it will not be available until Q2 2015.


2

The link you've provided does not mention SSH at all. SSH can be easily configured to use username/password and public key authentication. Major SSH implementation allow for the configuration of Kerberos authentication. But SSH does not allow the use of shared secrets for authentication. The protocol itself just doesn't support it. SSH isn't really ...


0

The "userID" you intend to introduce sounds like a second-factor authentication. So in order to access your system, an adversary needs to possess the device and also needs to know the user ID associated with the device. It adds a second layer of security, provided that the user ID is not printed on the device itself. Whether it is sufficient depends on the ...


1

Without an userID attacking your system can be done a million times faster than with userID. That seems like reason enough to me. With an userID an attacker can only attack one token at a time. Without userID he can with one try attack all 1 million at once.


0

There is no such thing possible till day. as Graham Hill said that you can use two layer authentication, mean when u login a code will be sent to you on mobile and than you have to enter that code and than you can see the inbox. Well apart from this Gmail is continuously capturing the location from where u loggged in. And benefit of this is if someone have ...


4

What you want is not possible, because there is no established trust relation between client and server and plain HTTP can not provide a secure way to establish this trust. Only HTTPS provides thus trust by checking the servers certificate against local trust anchors at the client, that is it infers the new trust from trust settings already built into the ...


0

Usually you have a constant realm and in this case HA1=MD5(username:realm:password) could be stored instead of the password. But, if the password is only used for the SIP account, it actually does not matter if within a attack against the provider username and password get seized or HA1 instead, because the latter is all it needs to authenticate as the user. ...


3

Cookies are domain-dependent. You don't decide, from the server side, which cookie you read; the browser sends the stored cookies that match the name (with domain) of the target server. If you want to share some authentication in some SSO manner, then you need both servers A and B to delegate the authentication to a common third server C. That server will ...


4

Unless "website A" and "website B" are both subdomains of the same domain, what you want to do is impossible; if they are subdomains of the same domain, the same person or organization presumably controls both. Consequently, legality is irrelevant.


0

In the situation you describe, a user with malicious intent (not you of course, but someone else with access to that public computer) will not have access to the previous person's password, and will only be able to use the other person's account until the session has expired (this time limit is determined by the website). However, while they are temporarily ...


1

I assume that you are referring to various different users, rather than one in particular (given that it is a public computer the chances of it being the same person every time is slim), so I would say that you are already doing the right thing. It could be tempting to go a little further and try to contact the user(s) and let them know what is happening, ...


1

Being able to generate a pair of keys with the same .onion address is of no help when trying to impersonate an existing service. Impersonation requires generating a key with an existing address, which is a preimage attack, not a collision attack, and so the full 80 bits of address length are providing security. 80 bits of security is considered adequate at ...


5

Your description is a bit confused and appears to be wrong. In particular, we see Alice computing here Diffie-Hellman half gKA and then proceed to send... her Diffie-Hellman secret KA to Bob, which is not at all what she should do. Plain Diffie-Hellman works the following way: Alice generates (randomly) her secret KA and computes gKA. Bob generates ...


0

I think there is some confusion about the access token and how it is used which can cause a security problem. It is correct that the tokens can be a security risk, but this depends on the information you are asking for from the service. A friends list is more information than first and last name for instance, but that information is not as vital as personal ...


0

The generic approach for a cache is to keep it in sync with the database. Right now you have some system, with RAM, that can decide whether a username+password is correct or not by checking with regards to its RAM contents, letting it flow to the database if the information is not in RAM (or is deemed too old in some way). If you can arrange for password ...


0

The idea behind this is that the code generated by Device A must be transmitted separately to Device B. Any method of communication will do: email, text message, phone call, etc. To answer your questions: How is the code calculated in the first place? From a keypair? This depends on the software of the device. Some vendors will generate a random 4 ...


-1

There is only one way for Alice to truly prove that Bob has received her message: Hand it to him Even with asymmetric keying, you can only have reasonable assurances that the communication channel is secure and that the intended recipient is receiving your messages. You can guarantee that Alice's private key was used to encrypt a message. You can ...


8

In practice, unless Bob sends a signed receipt, you are out of luck. The underlying cryptographic problem is called fair exchange. If you consider a network protocol such that Alice and Bob want to send each other some data elements (e.g. in your case an email from Alice to Bob, and a receipt from Bob to Alice; but it also works as a model for payments), ...


3

If you want to require Bob to let Alice know whenever Bob has received a message, as far as I know there isn't any such system built into the most common cryptographic systems. You would need to go outside of cryptography for a bit and require a server which tracks every time a message is downloaded from it. For instance, Alice could send a secret URL to ...


9

TL;DR Anyone can send a message and say it is from Alice if it is not signed; there is no way for Alice to prove that she didn't send those unsigned messages. However, Alice can prove she sent a message by signing it with a private key. Similarly, anyone can say Bob read a message, and Bob can't prove he didn't. But Bob can prove he read a message by signing ...


4

This does several things wrong. First, as Rory mentions in the comments, Don't Roll Your Own. Use HMAC, not an arbitrary hash function. This will actually protect you against length extension attacks. Second, you propose to encrypt your pseudo-MAC along with the message. Don't do this either. This is called MAC-then-encrypt, and it leaves you ...


4

Hard question to answer exactly. I'm going to refer to Theodore T'so's pwgen (v2.07) implementation exclusively here (pwgen -A0) These pronounceable passwords use "phonemes" as "symbols", rather than single characters, in (the English language biased) pwgen a phoneme can be 1 or 2 characters. There are 40 defined (in pw_phonemes.c), 25 are a single ...


8

Pronounceable words are more-or-less sequences of syllables. What constitutes a syllable depends on the language, including the language variant (British, Scottish, American, Indian... versions of English are not rigorously identical). So we will make some approximations. Let's suppose that we want two-letter syllables, always a consonant followed by a ...


6

I'm afraid not. You might be able to solve your problem with something called "two factor authentication" though. This is an option you can enable in Gmail where you will need to have your mobile phone with you whenever you log onto your mail. It is very easy to set up and highly recommended. If this won't fix your issue, edit your question to add some ...


4

Restricting yourself to only passwords that are pronounceable does decrease the entropy, which reduces strength. So in theory, the password will be weaker But password strength is a complicated beast. In particular, if choosing pronounceable passwords means you can remember a longer one than usual, then your entropy goes up and your password becomes ...


2

Basic auth credentials are transmitted with each and every request by the browser. Hence why you cannot traditionally "log out" without closing the browser. The reason why this approach works is because the browser is stateless. Normally when it sends a GET/POST/HEAD request it receives a 200 OK response. If it receives a 401 response it will prompt the ...


1

Technically you can store the access token in your database, and use it for API calls until it expires. It might be more trouble than its worth, though. For one thing, as Jonathan notes in his comment above, now you have to worry about securing your database and the data in it - these tokens give access to some fairly privileged information about your ...


3

The most pressing reason is that people login from multiple computers: home PC, laptop, tablet, work PC, friend's PC, internet cafe, etc. While it is theoretically possible to have a system that syncs your certificates - either through a cloud service, or a physical device you carry - this is beyond the capability of most users. Now, could someone create an ...


2

I see two major reasons: a certificate-based authentication is complex to explain. Today almost everyone understands how to use a password based authentication; Even if all the security rules (long enough, composed of a mix of digits, letters and special characters, most be changed from time to time, must not be shared...) are not always applied, almost ...


1

In my opinion, sudo for server admins is a bit overkill. If people log in, and they have root access (through some mechanism), they usually do maintaining tasks, where they will use sudo for >90% of the time. The purpose of sudo is to give accounts that are logged in some separation between untrusted applications and admin-like tasks, and make users aware ...


1

SSH authentication and security privileges are two different things, hence no point of having it as a default feature. However, it opens one more vector for attack(there is a CVE) and from my point of view makes it easier for users to overuse it, which is bad. On the topic of passwords, one way is to send a short-lived password to the user and require ...


0

The fourth factor would be something the individual does, (dynamic biometrics). Examples include recognition by voice pattern, handwriting characteristics, and typing rhythm.


1

When using a reliable two-factor authentication system, using a less secure password is reasonable. It's still best to use a difficult password generated by a password generator using upper and lower case, numbers, and symbols. But folks who will not do deploy such a secure password; in the case of a service that offers two-factor authentication, those ...


0

What would be the point of hashing the accessToken? We hash passwords because people reuse them everywhere. If they would not reuse passwords, we would not need to hash passwords, the application has been hacked after all (as the attacker gained access to the db), so all is already lost. accessTokens are not reused. and adding to security, are only used ...


1

You forgot the local physical attack! A long complex password makes shoulder spotting much less likely to succeed. Even if someone stares at my keyboard, he won't get my passwords unless he's Rainman. (cannot comment)


-2

I found a way to have a password for my Keepass vault that is easy to remember but at the same time virtually impossible to break which I named algorithmic passwords. To construct my password, I'm using a python shell. The basis for my password is a power tower which is a form of function that grows incredibly fast with few operations and numbers. For ...


3

While it is safer to make complicated passwords, I always recommend making them easy at the same time, and also have a uniqueness per website. The only way this would be a vulnerability is if you fall for a phishing scam, which is why it is important to have multiple ways to recover your email address, because your email is your way to recover other ...


4

Using a complex password for a single secure site is like using a special lock on your apartment door, which makes opening the door take longer and protects you better from 1% of all burglars Most answers deal with all kinds of attack scenarios, which could compromise your password, but to decide if a smaller password (6 Characters) is sufficient if you use ...


2

I do very similar, and the way I see it there are two major potential points of failure and I don't really have a good solution for one of them. First major risk is that LastPass itself is hacked and it's data dumped. While data is encrypted locally, my password used to encrypt that data is not very strong. LastPass has recognized that entering in a strong ...


4

There are issues with a couple of your assumptions. 309 million is a laughably small number if there is an offline attack. And on an offline attack, even with a good salt, the attacker will go after the low hanging fruit first. Ie. find the passwords that are in the dictionary, then the short passwords, then other simple passwords. How much of a problem ...


3

The UUID of your cellphone isn't a meaningful second factor as it can be spoofed. On the long passwords, it is reasonably secure to use long, sentence based passwords, but the amount of security provided drops DRASTICALLY if it has anything to do with what you are connecting to. It may still seem hard to guess, but establishing a relationship rather than ...



Top 50 recent answers are included