Tag Info

New answers tagged

0

The access security solution UserLock can prevent or limit concurrent logins on a Windows Server based network - this as part of a customized access control policy. It can be set by user, user group or OU and across all session types (workstation, terminal, IIS, VPN or Wi-Fi). There is no way in Windows native functionality to limit concurrent logins - i.e. ...


0

If you only accept certificates issued by you, and you validate that fact, then using the SKID has no security benefit over the serial number. If you use the serial number, and accept self-signed certificates (or any other certificates from CAs who aren't you), an attacker who knows the public key can impersonate users. Otherwise, there is no difference ...


1

FYI, I just encountered a case where a credential (possibly corrupt, since it showed up under an entry named with only two, odd Unicode characters) appeared only in the rundll32.exe keymgr.dll,KRShowKeyMgr interface, and not in the Credential Manager interface found in the Windows 7 control panel. So it may be worth checking both interfaces for cached ...


0

Identification requires that the verifier check the information presented against all the entities it knows about Authentication requires that the information be checked for a single, previously identified entity.


2

Why not keep it very simple: Examinee enters name + other identifying information (e.g. drivers license or passport number) on first page of test. That info will be shown an all subsequent test screens somewhere in the header or footer. Then he puts his drivers license on the table in front of him. Meanwhile you print out an ordered list of license ...


2

Attack vector: Examinees may easily swap drives during or after the test, if there is no pre-authentication of which examinee gets assigned which token. Using just the token is not sufficient, as examinees may pre-arrange an SSN swap. A gives B his SSN. B startes the exam, generating a token for A's SSN on his usb stick. After the exam is completed, B ...


0

so I don't think this is going to be 100% possible. What you can do is limit your servers to a single RDP session : https://support.managed.com/kb/a1816/how-to-enable-disable-multiple-rdp-sessions-in-windows-2012.aspx What you won't be able to prevent (I don't think) is someone using a console session at the same time (so MSTSC /admin) and the equivelent ...


1

You still have the same advantage. Two factor authentication with SMS/TOTP is based on two things : Something you know - your password Something you have - your phone If you log in using your phone you need to know the password and... have the phone. This way it's still the same amount of security.


1

I know several banks use "profiling data" from previous logins in order to try to determine the identity of the user based on: Credentials (obviously) Secret question (not all banks use this method though) IP address (Geo Location + time zone) and internet provider The device(s) previously used to communicate with the bank: a. Type of web browser, its ...


6

It is more secure than a password in some ways, but as you describe, it also makes accounts more vulnerable to other attack vectors. As a best practice, properly implemented two-factor authentication offers much superior security to a single factor, regardless if that single factor is a memorized password or an "on demand" password. Reduced Vulnerability ...


1

I wouldn't say there is anything wrong with your approach. Security people are just really into always using the accepted methodology. Take CSRF mitigation for example. There's a bunch of ways that successfully mitigate CSRF but security folks always recommend using a CSRF token because that's the accepted standard for mitigating CSRF attacks. I think the ...


0

Are there any blazing "Oh, don't do that!" security flaws in the setup summarized above? The basic protocol you are proposing is: client identifies themselves, server checks the public key and verifies that they are a valid user, server encrypts a challenge using the public key, client decrypts to get the challenge back and returns it as proof of ...


2

This is what I considered when determining what type of 2FA to use. Once I determined the solution type then I needed to identify which vendors were leaders in that space. I have the scoring document and all that if you want: EVALUATION CRITERIA ➢ Security/Compliance – Must be a secure solution that meets security standards as well as those of our ...


0

So I figured that you can save a hash key client side in a session/cookie. This basically means that anyone one the server will not be able to do anything with any information because they don't have the map that says this person is connected with this api/property. So client has 1 half of the key, and server has the other half of the key. I would hash this ...


1

You're generating 16 bytes which is 128 bits. Modern block and stream ciphers (i.e. AES) have a security margin of 128 bits, so it's reasonable to say that 16 bytes is sufficient. What I can't say for certain is whether or not openssl_random_pseudo_bytes() is sane enough to rely on.


2

The "keyed MD5" described in RFC 1828 can be summarized as follows: for key K and data D, the MAC value is MD5(K||D||K) (in the RFC, K is first padded to a length multiple of 512 bits, but it does not substantially change things here). To my knowledge, there is no known weakness to that construction, but there is not much security analysis either. HMAC has ...


1

Authentication methods Are you only authenticating or also other stuff? You might also need smartcards. Are you sure you only need SMS or do you also need to choose from a vast variety of tokens? Token You might want to choose a solution, which is not provided by a token vendor. The thing behind this is: You can keep the software system but easily mix and ...


0

To prevent brute force attacks, you would be better to do the following. 1) Ensure that passwords are complex enough. If given the chance a lot of users will use extremely simple passwords, like their name etc. Passwords should be at least 8 characters, and should include numbers, letters, and mixed case. 2) Lock-out IP's after 5 failed login attempts. It ...


1

I also discourage using email in this scenario. Obviously - if you are only using it internally - the attacker could only be internal (or an external first have to become interal). The email flow internally is probably more easy to sniff than dealing with the BTS for delivering the SMS. But both ways deliver the second component (to avoid the discussion ...


4

Part of the problem is that keeping the connection open while you wait for the delay to expire uses precious resources, particularly under certain popular configurations where the number of simultaneous connections allowed is pretty minimal. An ideal solution is to architect your system as follows: Design the logic first into the UI. A failed login ...


3

You want your server to do as little work as possible, to avoid DoSing yourself. Account lockout is great for DoSing your users. if count(unsuccessful authentications for user U) > threshold then demand solved CAPTCHA if count(unsuccessful authentications for password P) > threshold then demand solved CAPTCHA if dislike CAPTCHA then demand Proof of Work ...


1

They r feasibly safe in the sense that in order to compute 2^160 hash computations which r technologically infeasible. And you don't need to worry of downloading an .iso of windows while u can create an .iso from install.esd files from some1's Genuine windows copy(if u r little bit paranoid).


28

I assume that your intention with the failure delay is to prevent brute force attacks: if an attacker is trying to guess a user's password, she will first fail many times; if we can make those failures take a substantial amount of time longer, then it will make the attack an order of magnitude harder, and thus unlikely to succeed (in a reasonable time ...


5

A traditional delay would mitigate web browser based attacks, for example if someone uses phantomjs to automate login attempts the normal delay (in your case "more than one second") would be enough to stop anyone from trying to brute force a password, it just takes too long. However, most brute force attacks are not ran in web browsers but in scripted ...


1

I suggest to avoid even installing sudo on your systems: it's an additional attack vector with usually no justification for having it. I wrote an article on the sudo (mis)usage if you are interested to learn more on the topic: http://dmitry.khlebnikov.net/2015/07/should-we-use-sudo-for-day-to-day.html Re: the original question - if you need some privileged ...


6

Looking at OpenVPN's source code, this appears to be a cosmetic quirk of OpenSSL. When using --show-digests, OpenVPN calls OpenSSL's EVP_get_digestbynid() with, as parameter, all integers from 0 to 999. For some of these values, EVP_get_digestbynid() returns a non-NULL pointer that identifies the corresponding hash function implementation, and then OpenVPN ...


0

Here is the answer to related question which should resolve all of your confusion: How to securely hash passwords? EDIT: To question 1. As was said by other answerers, you can't prevent brute force by salting your passwords. Other techniques exists for this task, usually it's throttling of some kind and limiting number of attempts. Gradual throttling with ...


2

What you could do is hash the old passwords and make the users choose a new one when they login. You really need to force them to use new passwords though since if there's not a 100% chance that the old database was leaked their financial info could be exposed. If you think that the old system was compromised you'd be better off sending out emails, or ...


7

Simple version : Salts don't stop brute force attacks against a single user's password. What they stop is is you being able to do a brute force attack against all of the users' passwords at the same time.


21

From your initial understandings: A rainbow table is, for a given hash algorithm, an exhaustive map from hash outputs to inputs. Given that the table must cover the entire output range, and that a good hash algorithm makes it difficult to predict input from desired output, and expensive to compute the output, it should be very expensive to generate. As ...


0

From a security point of view, this should be fine provided the page protects against user enumeration and password guessing. It should validate the old user ID and password combination as a whole, and not specifically inform the user if the user ID does not exist - it should just output a generic error message: Your current user ID and password ...


0

Your first point is easily answer. There is nothing that prevents that. Salt are not a mean to avoid brute-force attacks anyway. Your second and third point are more relevant. Salts are here to avoid having one rainbow table to rule them all. That is to say, for each user, you have a different salt. This means that if you want to attack multiple users, you ...


2

Salt don't help against brute force attacks, as the attacker is firing all passwords known to men, he will eventually get lucky and guess it right. Salts become helpful when the stored passwords have been stolen, to find the password that belongs to the hash (I wouldn't use MD5) you can take a random password, hash it, and check it against the hash you ...


1

There are a number of ways of mitigating brute-force attacks, depending on the level of control and access you have to the systems in question. At a firewall level, you may be able to do rate limiting to throttle the number of connections from a given IP address. Also some firewalls will have Intrusion Prevention System capabilities which could allow for ...


0

I think there are pro/cons for both approaches. Remember that generally you need to think about a layered approach. First off, is this more useable, is it confusing the user, etc. More fields at one time may lead to more use confusion, typo frustration, etc. Perhaps the user gets frustrated and that results in them using a less complex password ...


0

In general, no. There are no significant additional security risks associated with this approach. Any attacker who can successfully change the user's password using a form like this could just as easily log in to the user's account and then change their password. Either way, the same information (username, current password, new password) is required. ...


4

For a malicious attacker who tries to alter an ISO file while keeping its hash value identical to the hash value of the "genuine" file, the problem is known as a second preimage attack. No such attack is known for SHA-1 right now; if somebody wanted to compute such a second preimage, he would have to pay a cost of about 2160 hash function computations, which ...


0

Breaking a knowledge factor have a theorical cost we can easily assure beyond human capability (a password with 12 dicewares words will never be unhashed using unbroken 256bit hash), if we exclude human vulnerability and implementation vulnerability (and the fact nobody use a 12 words password) this is a perfect security and provable as is. (as long as we ...


1

Normally the user needs to authenticate first in order to see the password change form. By entering the user name and password, the system should first authenticate the user and once authentication is successful, the password should be changed. This is something that can't be verified using the example URL you gave. However, in this case I would ...


0

One of possible risks is that such form doesn't require cookies or session support to login using stolen password and immediately change it. From the perspective of rogue software authors, there are many possible languages and frameworks, that can be used to create their software. Each of these require some knowledge to start. Eg. creating a bot that is ...


0

Yes, I'm fascinated by this as a possible passwordless authentication mechanism. And as you & others have already mentioned, it does offer the same security as most forgot-your-password systems ...although the better ones do require you to answer some kind of security question also, making it more like two-factor. Anyway Passwordless.org is good read ...


0

I'd say most of your arguments are valid. Typically certs used for signing have different key usage, for example "non repudiation". Many legal requirements (in various countries for example in EU) exists for digital signatures, if they shall be valid in court etc. These requirements do no exist on authentication certificates. All what you state as ...


4

For a low cost, hacked up solution, I'd look at tracking something that someone would be loath to share with someone else or be without. For that, I'd look at their phones. A simple WiFi access point that registers the MACs and IDs of devices on the network would work in your case, but it also has flaws. MACs and IDs can be modified, but it takes a little ...


2

Think for a moment about what your captcha is trying to accomplish. Here is the goal I can think of: Prevent a large-scale automated attack from breaking into weak accounts Here's a way to do that which will probably make your users happier: If a computer successfully logs in (as Bob), set a cookie on that computer so the server knows that computer ...


1

Adding a captcha after 10 or 100 failed attempts it useless, as most current bots have a deathbycaptcha account, and the API for dbc is really easy to use. So, showing a captcha every second time is a good thing, I think.


3

By definition, 2FA is if you authenticate users based on two of the following: Something you know (like a password) Something you have (like a key) Something you are (biometrics) I see that people often argue in which category e-mail should belong. Although many argue that it belongs in the "Something you have" category, I think that it should rather ...


3

Another way of attacking this might be to install a "honeypot". This is an ordinary input field which is included in the HTML together with the login fields (username, password), but this extra field is hidden using CSS. Typically, bots will try to enter text in all the fields shown in the HTML, so in PHP I checked that if the honeypot field were not empty ...


5

A captcha on a login screen makes no sense. I'm not surprised your users hated it. The purpose of captcha fields on forms is to prevent them being submitted by bots. A bot should not be able to login through your login screen, as it should not have valid credentials. If a bot can guess valid credentials, then you need to increase password strength.


3

Adding a Captcha or ReCaptcha is not a solution, it is merely an obstacle for both hackers and users. I have very good vision with my glasses and sometimes I can barely make out the image text. I would imagine that someone in denial about their vision is going to be infuriated. Everything you implement needs to have a specific purpose or else you just end ...



Top 50 recent answers are included