Solved Detect 4 Sequential/Consecutive characters within a string

A question for Jason:

Do you accept or reject a string such as "cCcc"?
Are you differentiating upper/lower case chars?
Hi,

Yes; with ebs17 code

I accept "cCcc" as not being repetitive and i am differentiating Upper/Lower..
 
on my original protect design after each keypress in the password field i display a picture representing how secure the password is depending on what characters have been typed and checked. The image represents stage conformity reached therefore 8 characters or more would be 20%, more than 2 Uppercase as well 40%, 2 lower aswell 60%, a special character 80% etc
A complete presentation of it as a small example database would certainly be of great value for the users of this forum, perhaps it would be well placed in the extra forum Sample Databases.
 
A complete presentation of it as a small example database would certainly be of great value for the users of this forum, perhaps it would be well placed in the extra forum Sample Databases.
Hi,

If you think it may help others; i will put something together (Strip away what's not relevant) and post here..
Will likely be Wednesday when i'm not at work...

Thanks for all your help...
 
You might want to add a description/header.
If it helps, I have this on my test version of the code from ebs17.
' ----------------------------------------------------------------
' Procedure Name: TestPassword
' Purpose: Routine to validate pwd
' Returns TRUE (valid password) IF:
' (Len(sPW) > 7) and ( more than 1 Number )and ( 1 or more Uppercase)
' and ( 1 or more Lowercase) and ( 1 or more SpecialCharacter)
' and (no more than 3 contiguous/repeat chars) and (differentiates upper/lower chars)
' So- cCcc pattern is valid/differentiates upper/lower | cccc is invalid as is CCCC
' Procedure Kind: Function
' Procedure Access: Public
' Parameter sPW (String): Password to be checked/validated
' Return Type: Boolean
' Author: ebs17 /AWF
' Date: 08-Jan-23
' ----------------------------------------------------------------
 
If it's made official then please clean up.
Code:
Dim sAll As String
This was a remnant from previous more extensive attempts and is now redundant. Maybe there is more, I assembled the function in a hurry.

The return from the function should be based on the following usage. A string can quickly deliver the individual values via split.
Code:
TestPassword = Len(sPW) & "|" & lNumber & "|" & lUppercase & "|" & lLowercase & "|" & lSpecialCharacter & "|" & _
                   UBound(Split(sSeries, "0|0|0|")) & "|" & UBound(Split(sSeries, "1|1|1|"))
Other alternatives to the string: - array, - arguments in the function as ByRef, - user-defined type
 
Last edited:
I was waiting for @arnelgp to reply, but it seems he's not around.
The following checks for 4 consecutive characters.

Code:
Function QuadChars(S As String) As Boolean

    Dim RE As Object
    Set RE = CreateObject("vbscript.regexp")

    With RE
        .Global = True
        .Pattern = "(\w)\1{3,}"
        .ignorecase = True
        QuadChars = .test(S)
    End With

End Function
Code:
?QuadChars("aabbb2222")
True

?QuadChars("aabbb222")
Flase

?QuadChars("aabbb1qQqq22")
True
 
Last edited:
What's more; on my original protect design after each keypress in the password field i display a picture representing how secure the password is depending on what characters have been typed and checked. The image represents stage conformity reached therefore 8 characters or more would be 20%, more than 2 Uppercase as well 40%, 2 lower aswell 60%, a special character 80% etc
Here is a moving progress meter you might find interesting. Click on speed check or the moving example.

 
Last edited:
another flavor:
Code:
Public Function hasConsecutive(ByVal strText As String, Optional ByVal intLenToTest As Integer = 4) As Boolean
Dim i As Integer, cnt1 As Integer, cnt2 As Integer
Dim ln As Integer, a As Integer, b As Integer, c As Integer
ln = Len(strText)
For i = 1 To ln
    If cnt1 = 0 Then
        cnt1 = 1: cnt2 = 1
    Else
        'first part, check for consecutive (up)
        'second part, repeating
        a = Asc(Mid$(strText, i - 1))
        b = Asc(Mid$(strText, i - 1)) + 1
        c = Asc(Mid$(strText, i, 1))
        If b = c Then
            cnt1 = cnt1 + 1
        Else
            cnt1 = 1
        End If
        If a = c Then
            cnt2 = cnt2 + 1
        Else
            cnt2 = 1
        End If
    End If
Next
hasConsecutive = (cnt1 > intLenToTest - 1) Or (cnt1 = ln) Or (cnt2 > intLenToTest - 1) Or (cnt2 = ln)
End Function
 
Last edited:
The password must not contain 4 consecutive characters (e.g. "1111", "1234", "abcd" )
I think, you are barking up the wrong tree here.
If you are using your own hand-made permission system for a plain Access application (=with Access backend) there are more serious security concerns than a password with 4 consecutive letters.

In any case, password length is a much more important factor. With your very low length requirement of only 8 characters, *every password* is a weak password.
 
I think, you are barking up the wrong tree here.
If you are using your own hand-made permission system for a plain Access application (=with Access backend) there are more serious security concerns than a password with 4 consecutive letters.

In any case, password length is a much more important factor. With your very low length requirement of only 8 characters, *every password* is a weak password.
I've been reverse engineering hardware and software professionally for over 35 years for Government, Public and Private Sector. Knowing you can never be completely secure does not mean we should not try implement good security policy. Its a legal requirement in many sectors to be seen to do just that. What were doing when taking measures to protect it's simply buying time. The password requirement is simply a nicely bit not relied on to protect data only the interface. What's important in a database is the data and my data is encrypted to AES(GCM)256Bit. Sure it can be reverse engineered however with a simple 8 character Password using a combination of upper/lower/special will take me 16 months roughly using an super fast hexcore processor to decrypt. Data that's that old could be considered redundant in many scenarios. You are right to raise the concern though; ignorance can not be used an excuse..
 
Sure it can be reverse engineered however with a simple 8 character Password using a combination of upper/lower/special will take me 16 months roughly using an super fast hexcore processor to decrypt.
Well, a quick internet search suggests the time to brute force an 8 character password with consumer hardware is currently 39 minutes.
 
To give a rough idea....
1673276728038.png


Taken from a two year old post at LinkedIn
 
If you choose to go to the trouble of using AES256 or any other 256-bit encryption standard using Galois Counter Mode (GCM) or any other method to generate your validation, a longer password is almost mandatory. The math on this is a true nightmare, but basically the shorter the password, the easier it is to crack, by a factor of just less than 100 for each character. If you consider an 8-character password, a 12-character password would be roughly 100 million times more secure. Your stated standards (two characters from each group) were in place for the U.S. Navy at least 15 and probably more like 20 years ago, except that they never recommended a password shorter than 14 characters. Before about 2005 they still allowed the "one from each group" requirement, but that got upgraded to "two of each" long before I retired.

Oddly enough, when I used to teach the Windows Security class, we sometimes got into a discussion about whether that requirement "N characters each from the upper, lower, digit, and special categories" actually LOWERED the security of the passwords by reducing the number of combinations available for use. Technically it does but it doesn't help password guessers and it is not enough of a diminution to significantly reduce the "hack time" on any mathematical attack.
 
Well, a quick internet search suggests the time to brute force an 8 character password with consumer hardware is currently 39 minutes.
It takes less than that for someone who knows what they are doing however the password in my project is not stored without encryption. If your saying AES even 128bit can be RE in 39 seconds then their dreaming.
To give a rough idea....
View attachment 105639

Taken from a two year old post at LinkedIn
 
If you choose to go to the trouble of using AES256 or any other 256-bit encryption standard using Galois Counter Mode (GCM) or any other method to generate your validation, a longer password is almost mandatory. The math on this is a true nightmare, but basically the shorter the password, the easier it is to crack, by a factor of just less than 100 for each character. If you consider an 8-character password, a 12-character password would be roughly 100 million times more secure. Your stated standards (two characters from each group) were in place for the U.S. Navy at least 15 and probably more like 20 years ago, except that they never recommended a password shorter than 14 characters. Before about 2005 they still allowed the "one from each group" requirement, but that got upgraded to "two of each" long before I retired.

Oddly enough, when I used to teach the Windows Security class, we sometimes got into a discussion about whether that requirement "N characters each from the upper, lower, digit, and special categories" actually LOWERED the security of the passwords by reducing the number of combinations available for use. Technically it does but it doesn't help password guessers and it is not enough of a diminution to significantly reduce the "hack time" on any mathematical attack.
Yes , absolutely spot-on.. I think by me posting requirements for a password check it's assumed that the requirement I needed is what I would consider secure. This is not the case; I was interested to see how it would be accomplished using VBA which could then be charged as necessary. Please don't misinterpret my origional post as suggesting that an 8 character password with the other validations would be considered safe. Far from it.. It would be reckless to consider as such and don't wish to suggest to anyone that it should be used. Just to point out I use a password of 32 characters in length as a minimum for anything where I need where data is considered sensitive.
 
It takes less than that for someone who knows what they are doing however the password in my project is not stored without encryption.

If the actual password is stored at all, even encrypted, you are already outside of USA Federal guidelines. Most Federal-compliant systems generate a 256-bit hashcode of the password string using a 4-digit or longer seed. Then when you try to log in, they regenerate the hashcode based on the seed and the input characters and then compare to the stored hashcode. This hides the actual length of the input password and, in fact, makes its actual length almost immaterial. This is sometimes referred to as the Purdy-S algorithm.
 
To give a rough idea....
View attachment 105639

Taken from a two year old post at LinkedIn
Yes, them figures are a little conservative to be fair. Many projects I have worked on with reference to RE identifies in most instances that the method of protection can be considered secure however time and time again the implementation of the method is so poor and misunderstood it may as well not be there. This I suspect is down to many things such as cost, knowledge and failing to understand what is trying to be achieved from an engineer point of view.
Here is a moving progress meter you might find interesting. Click on speed check or the moving example.
I think I'm missing a link..

Regards,
 
Sorry, here is the link

I think I'm missing a link..
 
Yes, them figures are a little conservative to be fair.

A few years ao when I was looking closely at security (or the lack of it) in Access, I purchased one of the password hacking tools and tested the time taken to obtain passwords of different lengths.
To do so I left the program running overnight several times (though it was often still chugging away in the morning) unless the password was very short/simple.

Where I gave it hints to narrow down the search e.g. exactly 8 characters including 1 upper case letter and one number then the search time was significantly reduced but it still usually took many hours. With no guidance given to the hacking tool, it took longer than the quoted times in that chart. Admittedly I'm using a 12 year old PC so my speed tests are always slower than the average but even so . . .

As for password length, the longest password that can be used to encrypt an ACCDB/ACCDE file is 20 characters.
You can enter far more but if you do so only the first 20 characters are actually used

NOTE: If its an encrypted BE file, only 19 characters can be used for passwords
 
If it is about password checking then also have a look at the function I wrote many years ago. It doesn't check for sequential characters but it does other good stuff.

 

Users who are viewing this thread

Back
Top Bottom